From: Evenbit on
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
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
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
"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
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 ;)

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Linux X demo
Next: where [BITS 32] directive?