Discussion:
Why is this assembly progarm not quitting on ESC?
(too old to reply)
Johann 'Myrkraverk' Oskarsson
2019-10-26 22:50:01 UTC
Permalink
Dear c.o.m.programmer and c.l.a.x86; 2nd posting attempt.

[Note: crossposted to c.o.m.p and c.l.a.x]

I am working my way through this 16bit assembly tutorial,

https://github.com/adamsmasher/sokobanDOS/tree/master/lesson2

except that I'm using the OpenWatcom assembler, wasm.

As far as I know, I've translated the nasm syntax to wasm correctly;
which is incidentally pretty similar to masm. And from reading the
code, I'm fairly certait *it should work* but doesn't. When I run it in
DOSBox-X, it doesn't quit when I press escape.

What am I missing here? I apologize for the lengthy code, it's the
complete tutorial lesson 2.

I'm compiling it like so,

wasm dostut2.asm
wlink sys dos com file dostut2.obj

and then running it in DOSBox-X. I'm fairly certain the problem is with
my code, and not in DOSBox-X.

Thank you.


;; file dostut2.asm
.286 ; we don't use bits 16 in wasm
.model tiny

.code
org 100h ; dos loads here
main proc
call installkb
call initvideo
gameloop:
call waitframe
cmp byte ptr [quit], 1
jne gameloop

call restorevideo
call restorekb

;; exit
mov ah, 4ch
mov al, 00h
int 21h
main endp

quit: db 0

include video.asm
include kb.asm
end
;; end of file: dostut2.asm

;;-----------------------------------------------------------------
;; file: video.asm
waitframe proc
push dx
;; port 0x3da contains vga status
mov dx, 03dah
waitretrace:
in al, dx ; read from port 0x03da into al
;; bit 3 will be on if we're in retrace
test al, 08h ; are we in retrace?
jnz waitretrace

endrefresh:
in al, dx
test al, 0x08 ; are we in refresh?
jz endrefresh

pop dx
ret
waitframe endp

initvideo proc
;; set mode to 0x13
mov ax, 13h
int 10h
ret
initvideo endp

restorevideo proc
;; return to text mode 0x03
mov ax, 03h
int 10h
ret
restorevideo endp
;; end of file: video.asm

;;-----------------------------------------------------------------
;; file: kb.asm
oldkbhandler: dw 0
oldkbseg: dw 0

installkb proc
push es
push bx
push dx
;; backup old kb interrupt
mov ax, 3509h
int 21h
mov [oldkbhandler], bx
mov [oldkbseg], es
;; install new kb interrupt
mov ah, 23h
mov dx, kbhandler
int 21h
pop dx
pop bx
pop es
ret
installkb endp

restorekb proc
push dx
push ds
mov ax, 2509h
mov dx, [oldkbhandler]
mov ds, [oldkbseg]
int 21h
pop ds
pop dx
ret
restorekb endp

kbhandler proc
push ax
in al, 60h ; get key event
cmp al, 01h ; esc pressed?
jne done ; if this is .done then wasm silently
mov byte ptr [quit], al ; doesn't create the object file.
done: mov al, 20h ; ack
out 20h, al ; send ack
pop ax
iret
kbhandler endp
;; end of file: kb.asm
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Rod Pemberton
2019-10-27 08:23:12 UTC
Permalink
On Sun, 27 Oct 2019 06:50:01 +0800
Post by Johann 'Myrkraverk' Oskarsson
Dear c.o.m.programmer and c.l.a.x86; 2nd posting attempt.
[Note: crossposted to c.o.m.p and c.l.a.x]
I am working my way through this 16bit assembly tutorial,
https://github.com/adamsmasher/sokobanDOS/tree/master/lesson2
except that I'm using the OpenWatcom assembler, wasm.
As far as I know, I've translated the nasm syntax to wasm correctly;
which is incidentally pretty similar to masm. And from reading the
code, I'm fairly certait *it should work* but doesn't. When I run it
in DOSBox-X, it doesn't quit when I press escape.
What am I missing here? I apologize for the lengthy code, it's the
complete tutorial lesson 2.
I'm compiling it like so,
wasm dostut2.asm
wlink sys dos com file dostut2.obj
and then running it in DOSBox-X. I'm fairly certain the problem is
with my code, and not in DOSBox-X.
Thank you.
[code snip]
The NASM code compiles and works on real hardware.

After some trivial tweaks (below), your code disassembles to the exact
same byte sequence as the NASM code with one exception.

That one exception is that ndisasm (nasm) shows that there are 100
zero bytes placed at the start of the .com file that shouldn't be
there. wdis shows that the 100 zero bytes are in the .obj produced by
wasm. wlink here complains about a missing entry address when linking.

I don't know enough about making .com's with OpenWatcom to know why
it's inserting the extra bytes, except it would seem to have something
to do with either the org or missing entry address. So, it could be as
simple as a missing entry address or wasm option (-bt=com) or wlink (op
start=<entry>) or similar. I tried a number of those things, but I
didn't get rid of the zero bytes.

The tweaks to generate the same code were:

1) kb.asm: 23h -> 25h
2) dostut2.asm: move ah,4ch; mov al,00h -> mov ax, 4c00h
3) dostut2.asm: switching around the include lines for kb.asm and
video.asm

Other than the typo, I'm assuming these have no effect, and that the
problem is the zero padding at the start of the .com since the binary
code is the same otherwise.


Rod Pemberton
--
Why are humans trying to un-bias A.I.? That's a human bias. Humans
don't want pure A.I. What humans want is slave-A.I.
Johann 'Myrkraverk' Oskarsson
2019-10-28 00:29:49 UTC
Permalink
Post by Rod Pemberton
Other than the typo, I'm assuming these have no effect, and that the
problem is the zero padding at the start of the .com since the binary
code is the same otherwise.
Thank you. I can get rid of the zero padding by simply dropping the
"org 100h" from the source.

That tweak, along with adding "public main" and "op start=main" to wlink
to get rid of the warning don't seem to change anything. The program
still runs and switches the graphic mode, then just sits there waiting
until I turn off DOSBox-X.

I was wondering if the problem is with my stack settings (none) but at
the moment I don't know how to explicitly set a stack.

The exercise has show me at least two bugs in wasm, where it will just
silently not generate the object file. There could be more. And wdis
doesn't seem to want to disassemble the com file.

I'll try the com file in VirtualBox and FreeDOS later, maybe the bug is
in DOSBox-X now.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Rod Pemberton
2019-10-28 06:16:01 UTC
Permalink
On Mon, 28 Oct 2019 08:29:49 +0800
Post by Johann 'Myrkraverk' Oskarsson
Post by Rod Pemberton
Other than the typo, I'm assuming these have no effect, and that the
problem is the zero padding at the start of the .com since the
binary code is the same otherwise.
Thank you. I can get rid of the zero padding by simply dropping the
"org 100h" from the source.
No. You need that for the correct offsets within the binary
instruction encodings.
Post by Johann 'Myrkraverk' Oskarsson
That tweak, along with adding "public main" and "op start=main" to
wlink to get rid of the warning don't seem to change anything. The
program still runs and switches the graphic mode, then just sits
there waiting until I turn off DOSBox-X.
If I do "public main" "op start=main", and keep the "org 100h", and the
other tweaks I posted, then the assembled .com code disassembles
exactly the same as NASM code. There is no 100 bytes of padding, and
it exits with ESC when run. Neither seem to do anything with graphics
here.
Post by Johann 'Myrkraverk' Oskarsson
I was wondering if the problem is with my stack settings (none) but
at the moment I don't know how to explicitly set a stack.
The issue seems to be that you need the link tweaks you posted above
plus "org 100h".

Good luck,


Rod Pemberton
--
Why are humans trying to un-bias A.I.? That's a human bias. Humans
don't want pure A.I. What humans want is slave-A.I.
Loading...