Prev: Linux X demo
Next: where [BITS 32] directive?
From: Evenbit on 31 Jul 2007 01:17 On Jul 30, 9:35 pm, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > The code below compiles and runs, but the ORG 100h is required, > otherwise some extra garbage gets printed out and things do not line > up properly. Yes, the OS prepends 256 bytes in front of our DOS-style "*.COM" program during the loading sequence, so we adjust the addresses accordingly. > > Are there any other things that might be a little more interesting that > can be added and/or changed in any way without getting too much > more complicated? Yes. You can delete the vestigial prepended "e" character from the register names if you feel like it. > > <code> > ; > ; Hello world! example. > ; Subsystem: DOS > ; > ; COMPILE_1: nasmw.exe -fbin -ohellow.com hello.asm > ; COMPILE_2: nasmw.exe -fbin -ohellow.exe hello.asm > ; LINK_1: NOT REQUIRED FOR .com or DOS .exe > ; LINK_2: > ; > org 100h > > lea edx, [sMsg] > mov eax, 0900h > int 21h > ; int 20h > mov eax, 4C00h > int 21h > > sMsg db "Hello World",0Dh,0Ah,"$" > > </code> > A common thing for folks to do while coding 16-bit COM programs is to also play around with video mode 13h because it is easy to code for. Here is an Etch-A-Sketch program that Beth posted a few years ago. Assemble with something like "NASM etch.asm -o etch.com" no other steps needed. I will follow it up with Annie's improvements but you will either have to obtain the A86 assembler or convert it to NASM syntax (shouldn't be too difficult). -------------------- 8< --------------------- ; Etch.asm: ; Etch-a-sketch simulation program ; ; keys: ; a = move up ; z = move down ; , = move left ; . = move right ; s = shake etch-a-sketch (clears drawing) ; esc = quit ; org 100h mov ax, 0013h int 10h mov di, 0A000h mov es, di mov di, (99 * 320) + 159 NextPixel: mov byte [es:di], 15 mov ah, 00h int 16h cmp ah, 01h je QuitProgram cmp ah, 1Fh jne NotShake mov ax, 0013h int 10h NotShake: cmp ah, 1Eh jne NotMoveUp sub di, 320 NotMoveUp: cmp ah, 2Ch jne NotMoveDown add di, 320 NotMoveDown: cmp ah, 33h jne NotMoveLeft dec di NotMoveLeft: cmp ah, 34h jne NotMoveRight inc di NotMoveRight: jmp NextPixel QuitProgram: mov ax, 0003h int 10h ret -------------------- >8 --------------------- ; ; ETCH.ASM ; Etch-a-sketch simulation program ; ; Original DOS code by Beth Stone. ; ; Adapted to A86 syntax, with enhancements, by Annie. ; ; To assemble with A86: A86 ETCH.ASM ; ; Control keys: ; ; Up Arrow: move up ; Down Arrow: move down ; Left Arrow: move left ; Right Arrow: move right ; C: clear the drawing ; ESC: quit ; code segment org 100h mov ax,0013h int 10h mov di,0A000h mov es,di reset: ; ; Light up the VGA border. ; mov ax,1001h ;function 10h, sub-function 1 mov bh,5 ;set color in BH (5 = magenta) int 10h ;call ROM BIOS video services mov di,(99 * 320) + 159 NextPixel: mov byte [es:di],11 mov ah,00h int 16h cmp ah,01h je exit cmp ah,2Eh jne NotShake mov ax,0013h int 10h jmp reset NotShake: cmp ah,48h jne NotMoveUp sub di,320 NotMoveUp: cmp ah,50h jne NotMoveDown add di, 320 NotMoveDown: cmp ah, 4Bh jne NotMoveLeft dec di NotMoveLeft: cmp ah,4Dh jne NotMoveRight inc di NotMoveRight: jmp NextPixel exit: mov ax, 0003h int 10h int 20h end Nathan.
From: SpooK on 31 Jul 2007 10:42 On Jul 30, 11:49 pm, Evenbit <nbaker2...(a)charter.net> wrote: > The only API calls that you need are GetStdHandle and WriteFile. But > you can avoid those (if you don't mind a bit of bloat) if you employ > the services of a nifty C library. Try this: Win32 demos 11 and 12 of the NASM32 Project (http:// www.asmcommunity.net/projects/nasm32/) highlight both of these methods ;)
From: Evenbit on 31 Jul 2007 17:18 On Jul 30, 9:35 pm, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > > Are there any other things that might be a little more interesting that > can be added and/or changed in any way without getting too much > more complicated? > > <code> > ; > ; Hello world! example. > ; Subsystem: DOS > ; > ; COMPILE_1: nasmw.exe -fbin -ohellow.com hello.asm > ; COMPILE_2: nasmw.exe -fbin -ohellow.exe hello.asm > ; LINK_1: NOT REQUIRED FOR .com or DOS .exe > ; LINK_2: > ; Just because you give the file an "exe" extension does not automatically make it into a standard DOS executable. Since it doesn't contain the proper header, the OS loader will assume it to be a typical "com" program and treat it as such. If you go here: http://sourceforge.net/project/showfiles.php?group_id=6208 ....scroll down to the "DOS 16-bit binaries (OBSOLETE)" heading and get the 0.98.38 archive (the newer 0.98.39 lacks this for some reason) which contains a "misc" directory with a few useful include files that define macros and such. The "exebin.mac" provides the needed header to create a proper DOS "*.exe" program using NASM. It is reprinted below: ; -*- nasm -*- ; NASM macro file to allow the `bin' output format to generate ; simple .EXE files by constructing the EXE header by hand. ; Adapted from a contribution by Yann Guidon <whygee_corp(a)hol.fr> %define EXE_stack_size EXE_realstacksize %macro EXE_begin 0 ORG 0E0h section .text header_start: db 4Dh,5Ah ; EXE file signature dw EXE_allocsize % 512 dw (EXE_allocsize + 511) / 512 dw 0 ; relocation information: none dw (header_end-header_start)/16 ; header size in paragraphs dw (EXE_absssize + EXE_realstacksize) / 16 ; min extra mem dw (EXE_absssize + EXE_realstacksize) / 16 ; max extra mem dw -10h ; Initial SS (before fixup) dw EXE_endbss + EXE_realstacksize ; Initial SP (1K DPMI+1K STACK) dw 0 ; (no) Checksum dw 100h ; Initial IP - start just after the header dw -10h ; Initial CS (before fixup) dw 0 ; file offset to relocation table: none dw 0 ; (no overlay) align 16,db 0 header_end: EXE_startcode: section .data EXE_startdata: section .bss EXE_startbss: %endmacro %macro EXE_stack 1 EXE_realstacksize equ %1 %define EXE_stack_size EXE_bogusstacksize ; defeat EQU in EXE_end %endmacro %macro EXE_end 0 section .text EXE_endcode: section .data EXE_enddata: section .bss alignb 4 EXE_endbss: EXE_acodesize equ (EXE_endcode-EXE_startcode+3) & (~3) EXE_datasize equ EXE_enddata-EXE_startdata EXE_absssize equ (EXE_endbss-EXE_startbss+3) & (~3) EXE_allocsize equ EXE_acodesize + EXE_datasize EXE_stack_size equ 0x800 ; default if nothing else was used %endmacro As far as I can tell, the GNU LESSER GENERAL PUBLIC LICENSE Version 2.1 applies to the above code snippet. Nathan.
From: Jim Carlock on 31 Jul 2007 19:26 "SpooK" wrote: : Win32 demos 11 and 12 of the NASM32 Project : http://www.asmcommunity.net/projects/nasm32/ : highlight both of these methods ;) Thanks... Next question... where do I get kernel32.inc from? Do I need to convert a C header file (kernel32.h)? In the past I hand-typed the constants into the files, converting VB source code into something NASM understands. And that works great, because no one in VB uses include files (.h or .inc) so things flow kind of naturally and all get placed where they are needed. Just found it in the nasm32-07-09-2006.zip file. Can I make a request? <g> Use YYYYMMDD date formats. It makes sorting things a bit easier. I don't know how others feel about this, so perhaps let some others jump in and comment on it as well. And I might as well get some help on how to convert the .h files into ..inc files. So if someone can offer some advice there, that would be great. Thanks, Keith. -- Jim Carlock
From: SpooK on 31 Jul 2007 19:44
On Jul 31, 6:26 pm, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > "SpooK" wrote: > > : Win32 demos 11 and 12 of the NASM32 Project > :http://www.asmcommunity.net/projects/nasm32/ > : highlight both of these methods ;) > > Thanks... NP. > Next question... where do I get kernel32.inc from? Do I need > to convert a C header file (kernel32.h)? It's in the NASM32 package (which I think you realize below???) > In the past I hand-typed the constants into the files, converting > VB source code into something NASM understands. And that > works great, because no one in VB uses include files (.h or .inc) > so things flow kind of naturally and all get placed where they are > needed. > > Just found it in the nasm32-07-09-2006.zip file. The kernel32.inc and others??? > Can I make a request? <g> Use YYYYMMDD date formats. It > makes sorting things a bit easier. I don't know how others feel > about this, so perhaps let some others jump in and comment on it > as well. I usually use the YYYYMMDD format myself (especially for DynatOS build numbers) but the current format is what Bryant had to begin with so I just left it... most are just aware enough to pick the version that is on top. I'll see about changing that format once there is another release, but until then... > And I might as well get some help on how to convert the .h files into > .inc files. So if someone can offer some advice there, that would be > great. -----> http://www.japheth.de/h2incX.html <---- although it is MASM- specific. I thought about designing one for the NASM32 Project... eventually... like everything else :P Currently (as in I started this a long time ago and haven't done since) I am hand-converting the X11 header file to a NASM32 include files. I actually started the XBOX stuff after starting the X11 header and as you can see it is already released while the X11 header is yet to be released. I still want to get another major CVS update of DynatOS done before I get back to working on NASM32, so have some patience all those *NIX users ;) |