8086 assembler

[maxfourier]

All i need is a 8086 assembler. That is something that looks like Notepad/text editor and runs assembly level code like (the following)


-------------------------
.model small
.stack 100h

.data
msg db 'Hello, world!$'

.code
start:
mov ah, 09h ; Display the message
lea dx, msg
int 21h
mov ax, 4C00h ; Terminate the executable
int 21h

end start
---------------------

And thats it! But nothing works. I search everywhere. First i found this 8086 emulator (emu8086). Then i tried various assemblers. But seriously, I can do nothing. All of them (thier exe's) just flash a Dos window for a milisecond and then just disappear. (NGASM, FASM, AdaptAsm, A86, TASM) I tried doing that cmd stuff but it dint work. Plus i don't want to get into that. Is there something that work and is Zen, Minimal?

I have this Douglas Hall text which tells me all kinds of stories about 8086 instructions which i can get in any manual but it dosent tell me how to assemble programs & it wont even give me the name of an assembler.

Moreover, there's nothing on youtube. Someone needs to make assembly level tutorials like thenewboston or something. Starting from zero..

Give me a link or something. I can't (don't want to) learn the instructions for my exams without actually doing the programming.

 

[rmain1972]

The window probably flashes because your program runs so quickly. Make a batch file that runs your program and then pauses to let you see the output.

 

[maxfourier]

It is not my program that flashes but the assembler's exe file. Where is the notepad like thing i'm looking for?

 

[maxfourier]

I haven't even started writing code. Just tell me a good assembler and help me assemble my first program. I will never ask for anything else

 

[carbonzit]

It sounds like your problem is simply that you're not using a DOS "command window", but somehow running the emulator from Windows directly--is that the case? If so, then what you see is the expected behavior: you invoke the program (the program being DOS itself in this case), which executes, loading and running your little program in a few milliseconds, then it exits, closing its window.

Depending on which version of Windoze you're using, you should be able to open a DOS window and run your program in that window, in which case you'll see any output it writes to that window.

I use TASM, 'cause I happen to have an old copy of it I used long ago. Probably can pick it up for free somewhere. It works fine for me, but I work in the DOS "environment" when I assemble, link and run assembly-language programs.

I know quite a bit about 8088 (so-called "8086", although nobody ever really ran it on that processor!) assembly language, and would be glad to help you if you have specific questions about it. It was my first real computer language, and I still like to use it occasionally.

 

[maxfourier]

Can you tell me the steps to make a program with TASM?

 

[Nigel Goodwin]

Can you tell me the steps to make a program with TASM?

Presumably you write your program using a text editor, save it as a plain text file (DOS filename only), and then run TASM on it (such as 'TASM assembler.asm'.

 

[Ratchit]

maxfourier,

I have found that IDEs (Integrated Development Environment), which combine a text editor, language, and a linker are more trouble than they are worth. I always use a plain text editor and a batch file to assemble and link. The assembler puts out a list file which can be looked at with any text reader. For a DOS batch file, you can pipe the output to a file with the ">" command if it zips through without stopping, or use the "pause" command in the batch runstream.

Is it really necessary to learn old ways with DOS? Really, Windows 32 bit programming is much easier because you don't have to contend with tricky segment registers. It has a flat memory model and the 32 bit instructions are more powerful. Plenty of tutorials around, too. Try it, you will like it.

Ratch

 

[carbonzit]

Totally agree with Ratchit's comments regarding IDEs. Stick to text-based, command-line stuff.

The "old school" approach (the segmented-memory model under DOS, no protected mode) is still simpler by far than writing 32-bit code. And for the programming I do, and I suspect what the O.P. is trying to do, none of the benefits of the "new" way (flat memory model, fancy 32-bit instructions, etc.) are really unnecessary. But then, it's also a matter of preferred style.

Anyone know where one can get a copy of TASM (or MASM or some similar command-line assembler)? Plus don't forget you need a linker (I use TLINK).

The other tradeoff is that you need a resource compiler to create a 32-bit Windoze program, rather than just the assembler and linker. I had wanted to play around with 32-bit ASM programming, but could never find a free resource compiler that works. (The resource compiler ties all the non-code stuff, like icons, dialogs, custom controls, etc., into the executable program.)

Regarding your comment about "tricky segment registers", what I like to do is to create .COM programs instead of .EXEs. Lots of folks don't realize you can still do this, at this late date, by linking to an .EXE and using the EXE2BIN utility. .COM programs are truly primitive: limited to 64K in length (size of executable file) and non-relocatable. But they give an elegantly simple solution to all that futzing around with segment registers. When a .COM program loads, all of the segment registers (CS, DS, ES and SS) point to the same segment. You don't have to do anything to any segment register (well, unless you're doing something fancy in your program, like carving out separate data segments). What could be simpler? (And a big noisy rasberry to those purists who insist that one should never mix data and code in the same segment: it worked fine in 1974, and it still works fine today!)

 

[maxfourier]

Thanks everyone for the help. I got it now.

 

[Ratchit]

carbonzit,

The "old school" approach (the segmented-memory model under DOS, no protected mode) is still simpler by far than writing 32-bit code. And for the programming I do, and I suspect what the O.P. is trying to do, none of the benefits of the "new" way (flat memory model, fancy 32-bit instructions, etc.) are really unnecessary. But then, it's also a matter of preferred style.

First of all, if you need to directly access the input/output (I/O)ports of your box, then you need DOS. Windows jealously guards access to the I/O ports, so the only way you can access the ports with Windows is to use the driver usually supplied by the manufacturer of the device.

But, if you are just writing a "Hello World" program or any other Windows program, it is very easy once you know how. Just read the first two simple tuts at this link **broken link removed** to get a taste of what it it like.

If you like what you see above, then go over to http://www.masm32.com/ and look at the "myths" and "why" sections. If you still like what you see, then you can download the free package which contains the Masm Assembler, libraries, Masm Linker, resource compilier, runstreams, and IDE editor if you want it. In other words, it contains the whole weapons system. I have written plenty of 32-bit Windows programs, so I can attest that you can do more with less effort with 32-bit Windows programming. Windows does much of the scut work of maintaining scroll bars, window sizing, and mouse pointer housekeeping for instance. You can ask questions in the Masm Forum, which is directly linked at the above site, or I can help you, too. Try it, and you will probably like it.

Ratch

 

[carbonzit]

Hey, thanks, I might just take you up on that!

But before I go ahead and download it, tell me: are these tools usable in old-fashioned manner (i.e., from a DOS command line)? Do I need to use the IDE? Can I run it with batch files and such?

Not that I love DOS or anything, but I'm just used to that kind of workflow. Unless they make it super-easier or something.

 

[Ratchit]

carbonzit,

But before I go ahead and download it, tell me: are these tools usable in old-fashioned manner (i.e., from a DOS command line)?

Yes, the assembly, resource compiler, and linker are DOS executable programs. The output is a program that runs as a Windows application. I have a "template" batch file that contains all I need to build a Windows program. All I have to do is edit it for the file name, comment out the call to the resource compilier if not needed, and then run it.

Do I need to use the IDE?

Hell no, I sure don't.

Can I run it with batch files and such?

Hell yes, I sure do.

Ratch

 

[maxfourier]

Hey, is [mov ax, ffffh] a valid instruction?

 

[carbonzit]

Sure, it's just an immediate move (of a constant) into AX. Used all the time.

(Except that I think you need to make that 0FFFFH to make the assembler recognize it as a number.)

 

[OlPhart]

As my handle...

I'll point that mixing data & pgm in a segment isn't an issue Until you're looking at someone elses' code.

Oh, the 8086 predates the 8088, and it's a specious consideration... they're the same core. Package aspects "shoehorned" the 8 bit bus 8088 from the 16 bit native 8086. The Intel architecture Still Sucked compared to Zilog and especially Motorola.

Once you play with an orthogonal instruction set in a linear address space, you realize "pages" are for books. Just a Geezer spoutin' & sputterin'... <<<)))

(an orthogonal instruction set means any instruction applies to all addressing & register modes) Compare Motorola 68000 vs 8086, but not just after a meal...

 

[carbonzit]

I'll point that mixing data & pgm in a segment isn't an issue Until you're looking at someone elses' code.

Wouldn't be an issue in my programs; I document my code thoroughly. Mostly so's I can understand the damn things when I look at them 10-15 years later.

Oh, the 8086 predates the 8088, and it's a specious consideration... they're the same core.

Yes, but the fact still remains that 99.9% of those who use "8086" assembler never ran it on an actual 8086. Like many, possibly including yourself, I started on the 8088. So the moniker is a misnomer.

Package aspects "shoehorned" the 8 bit bus 8088 from the 16 bit native 8086. The Intel architecture Still Sucked compared to Zilog and especially Motorola.

Yeah, yeah. I'm still looking for my copy of David Bradley's 8088 assembler book, which explains something about why IBM decided to go all cheap with the 8088 instead of spending the extra 25 cents (metaphorically speaking) for a 16-bit bus (as well as other less-known defects of the system).

And of course we can endlessly armchair-quarterback the '88's deficiencies compared to the Z80, 68000, etc. But once you learn your way around segmented architecture, learn what must be on a 16-byte boundary (and what must not cross it!), and all the other annoyances associated with Intel's processor, one can still write useful and elegant programs, and even, yes, have fun with it.

(So quitcherbellyachin'!)

 

[OlPhart]

Yup, I'll go ya Point 1: but I've been stuck trying to decipher someone elses' code, to Much gnashing of teeth and subverbal cursing.

Point 2: Yup, I never ran it in native 16 bit, the hardware was more to build than the performance required.

Point 3: I can only suspect that cost was SO sensitive that the board layout and components for 16 bit didn't justify the performance penalty. Since they were "first", a comparative value was irrelevant. I still favored the "coco/6809": cheap, fast & usually enough.

As for who "won" the architectural war, look at the survivors and their respective market segments.

It's a discussion / debate that has no "winner" just viewpoints & merits. (but good for a grin)... <<<)))

 

[carbonzit]

I still say that the 80286 is one of the most under-utilized (and under-appreciated) machines that humans ever created. It's pretty much gone into the great recycle bin of history. (Not that it didn't have massive defects compared to the '386 regarding protected-mode security; it did. My point is that no computer, to my knowledge, ever really took full advantage of all the computing power in that chip.)