Debugging help for protected mode entry+exit experiment

[awik]

Hi,

I'm trying to learn how to use some features of the 80386+ protected mode, in particular V86 mode. Before I get to that stage however, I need to establish code to successfully enter and exit protected mode.

I am developing and testing my program under VMware ("Player", the free version). I am wondering if the emulation might be broken/faulty, but if that were so, why would Win98 work properly?

I've been debugging this for days, and I am out of ideas. I'm posting the whole program below -- the PM entry/exit code is near the top. Below are interrupt handlers (really simple stubs), and the GDT and IDT tables. I'm using direct writes to the video memory at 0xB8000 to output debugging flags. Sometimes, for some reason (help!), stage "C" (referring to the debugging output) is reached and interrupt 8 (timer, IRQ0) is working, as is verified by the "08" debug output and the following character that is incremented each time the interrupt is triggered. Sometimes, I get an interrupt "09" (keyboard). Sometimes, I can't reach even stage "B" before it locks up or reboots (VMware says the CPU has entered shutdown state).

The test/development platform is MS-DOS (the version that comes with Win98SE).

OK, the code:

Code: Select all

ORG 100h
SEGMENT	_TEXT ;start=0 vstart=100h

RMMSGID_V86ALREADY EQU 0
RMMSGID_DOSRESIZE  EQU 1
RMMSGCOUNT	   EQU 2

main:
CPU 386
BITS 16
	smsw	ax
	test	ax, 1
	jnz .v86already
	;
	mov	sp, stack_ends
	mov	bp, bss_starts
	;
	mov	bx, sp
	add	bx, 15
	shr	bx, 4
	mov	ah, 4Ah
	int 21h
	jc .dosresize
	;
BSS_GDTR  EQU  2    ; align properly at odd word address
	mov	word [bp+BSS_GDTR], our_gdt.end-our_gdt-1  ; GDT upper limit
	mov	ax, cs
	xor	dx, dx
	mov	dl, ah
	mov	cl, 4
	shr	dx, cl
	shl	ax, cl
	add	[our_gdt.sel08+2], ax  ; base addr bits 0-15
	adc	[our_gdt.sel08+4], dl  ; base addr bits 16-24
	add	[our_gdt.sel10+2], ax  ; base addr bits 0-15
	adc	[our_gdt.sel10+4], dl  ; base addr bits 16-24
	mov	cx, ax  ; save
	mov	bx, dx  ;  "
	add	ax, our_gdt
	adc	dl, 0
	mov	[bp+BSS_GDTR+2], ax  ; GDT lin. addr; low word
	mov	[bp+BSS_GDTR+4], dx  ; " high word
BSS_OLD_SEG EQU 8
BSS_IDTR    EQU 0Ah  ; should be at odd word addr.
BSS_SAVE_IDTR EQU 0x12 ; likewise
BSS_SAVE_GDTR EQU 0x1A ; likewise
int3
	sgdt	[bp+BSS_SAVE_GDTR]
	sidt	[bp+BSS_SAVE_IDTR]
	mov	word [bp+BSS_IDTR], our_idt.end - our_idt - 1 ; IDT limit
	mov	ax, cx  ; restore ax
	mov	dx, bx  ;  and dx
	add	ax, our_idt
	adc	dl, 0
	mov	[bp+BSS_IDTR+2], ax
	mov	[bp+BSS_IDTR+4], dx
	mov	[bp+BSS_OLD_SEG], cs
	;
int3
mov ax,0xB800
mov es, ax
mov di, (24*80+79)*2
mov ax, 0x0F00 + 'A'
stosw
int3
	; fixup selector part of IDT entries
	mov	cx, (our_idt.end - our_idt) / 8 + 1
	mov	di, our_idt+2
.iloop:	mov	word [di], 08h  ; 08 is code segment selector.
	add	di, 8   ; advance 1 IDT entry.
	loop .iloop
call waitesc16
in al,70h  ; disable NMI
or al,80h
out 70h,al
	cli
	lgdt	[bp+BSS_GDTR]
	lidt	[bp+BSS_IDTR]
	mov	eax,cr0
	or	al, 1
	shl	eax,1	; clear
	shr	eax,1   ;  paging bit
	mov	cr0,eax
mov ax, 10h  ; data/stack selector
mov ds, ax
movzx esp,sp
mov ss, ax
add al, 8	; 18h = video selector
mov es, ax
mov di, (24*80+79)*2
mov ax, 0x0F00 + 'B'
stosw
call waitesc16
push word 08h
push dword .pm32ent
retfd
ALIGN 4
.pm32ent:
BITS 32
mov eax,ebp
shr eax, 16
test ax, ax
mov edi, (24*80+78)*2
mov ax, 0x0F00
jz .skip1
mov al, 'B'
stosw
jmp .skip2
.skip1:
mov al, 'N'
stosw
.skip2:
movzx esp,sp
movzx ebp,bp
mov edi, (24*80+79)*2
mov ax, 0x0F00 + 'C'
stosw
sti
call waitesc32
	cli
	mov	eax,cr0
	and	eax, ~(1|0x80000000)  ; clear PE and PG bits
	mov	cr0,eax
	lidt	[bp+BSS_SAVE_IDTR]
	lgdt	[bp+BSS_SAVE_GDTR]
mov ax, 0xB800
mov es, ax
mov ax, [bp+BSS_OLD_SEG]
mov ds, ax
mov ss, ax
call waitesc32
;.kbloop2:
;in al, 60h
;cmp al, 1
;jne .kbloop2
mov edi, (24*80+79)*2
mov ax, 0x0F00 + 'D'
stosw
mov ax,[bp+BSS_OLD_SEG]
mov cs,ax
push word cs
;push word 0
push dword .exit32
retfd
.exit32:
BITS 16
mov edi, (24*80+79)*2
mov ax, 0x0F00 + 'E'
stosw
.kbloop0:
in al, 60h
cmp al, 1
jne .kbloop0
;sti
mov edi, (24*80+79)*2
mov ax, 0x0F00 + 'F'
stosw
.kbloop1:
in al, 60h
cmp al, 1
jne .kbloop1
BITS 16
mov ax,4C00h
int 21h

............. snip for brevity

BITS 32
waitesc16:
	pushf
	push	ax
.1:	in	al, 60h
	cmp	al, 1
	jne .1
.2:	in	al, 60h
	cmp	al, 1
	je .2
	pop	ax
	popf
	retn

waitesc32:
	pushfd
	push	eax
.1:	in	al, 60h
	cmp	al, 1
	jne .1
.2:	in	al, 60h
	cmp	al, 1
	je .2
	pop	eax
	popfd
	retn


BITS 32
int_00:
	pushad
	push	es
	mov	ax,18h
	mov	es, ax
	mov	edi, (16*80+0)*2
	mov	ax, 0x0F00 + '0'
	stosw
	mov	al, '0'
	stosw
	pop	es
	popad
	iretd

........................ snip for brevity

int_08:
	pushad
	push	es
	mov	ax,18h
	mov	es, ax
	mov	edi, (16*80+32)*2
	mov	ax, 0x0F00 + '0'
	stosw
	mov	al, '8'
	stosw
	inc	byte [es:edi]
	mov	al, 60h		; specific EOI for IRQ0
;	mov	al, 20h		; non-specific EOI
	out	20h, al
	pop	es
	popad
	iretd

int_09:
	pushad
	push	es
	mov	ax,18h
	mov	es, ax
	mov	edi, (16*80+36)*2
	mov	ax, 0x0F00 + '0'
	stosw
	mov	al, '9'
	stosw
	inc	byte [es:edi]
	mov	al, 61h		; specific EOI for IRQ1
;	mov	al, 20h		; non-specific EOI
	out	20h, al
	pop	es
	popad
	iretd

........................................ snip for brevity

SEGMENT _DATA

..................................... snip

ALIGN 8
; SELECTOR FORMAT
;15                              8  7                 4  3  2      0
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+
; |                      INDEX                         |LDT|  DPL  |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+
; 
; DESCRIPTOR FORMAT:
;
;15                              8  7                              0  BYTE
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+
; |       BASE 24-31              || G |D/B| L |AVL|  LIMIT 16-19  |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +6
; | P |  DPL  | S |      TYPE     ||       BASE ADDRESS 16-23      |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +4
; |                       BASE ADDRESS 0-15                        |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +2
; |                           LIMIT 0-15                           |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+   0
;
; TYPE field:
;  3             0
; +---+---+---+---+
; |C/D|   |   | A |  C/D=code/data; 1=code, 0=data.  A=accessed
; +---+---+---+---+
; | 0 | E | W | A |  E=expand down, W=write access
; +---+---+---+---+
; | 1 | C | R | A |  C=conforming, R=read access
; +---+---+---+---+

our_gdt:
	dd 0, 0		; entry 0: unused
.sel08: ; code segment selector (32-bit)
	dw 0xFFFF  ; +0  limit bits 0-15
	dw 0       ; +2  base addr. 0-15
	db 0       ; +4  base addr. 16-23
	db 0x9B    ; +5  PDdSType, *P=present, D=DPL, S=0=system descr. type
	db 0x40    ; +6  GBLALimt, G=gran., B=32bit, L=64bit-, A=avail.
	db 0       ; +7  base addr. 24-31
.sel10: ; data and stack segment selector (16-bit)
	dw 0xFFFF  ; +0  limit bits 0-15
	dw 0       ; +2  base addr. 0-15
	db 0       ; +4  base addr. 16-23
	db 0x93    ; +5  PDdSType, *P=present, D=DPL, S=0=sys.desc, d.seg+w
	db 0x40    ; +6  GBLALimt, G=gran., B=32bit*, L=64bit-, A=avail.
	db 0x00    ; +7  base addr. 24-31
.sel18: ; text mode VGA memory
	dw 0xFFF   ; +0  limit 4095
	dw 0x8000  ; +2  low 16 bits of base addr.
	db 0x0B    ; +4  bits 16-23 of base addr.
	db 0x93    ; +5  PDdSType, *P=present, D=DPL, S=0=sys.desc, d.seg+w
	db 0x00    ; +6  GBLALimt, G=gran., B=16bit*, L=64bit-, A=avail.
	db 0x00    ; +7  base addr. 24-31
.end:

; INTERRUPT GATE DESCRIPTOR FORMAT:
;
;15                              8  7                              0  BYTE
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+
; |                          OFFSET 16-31                          |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +6
; | P |  DPL  |S=0| D   1   1   0 || 0   0   0 | -   -   -   -   - |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +4
; |                            SELECTOR                            |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+  +2
; |                           OFFSET 0-15                          |
; +---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---+   0
; D=size of gate; 1=32 bits.
our_idt:
.ent00:	dw int_00  ; offset bits 0-15
	dw 0       ; selector
	db 0x00    ; bits 0-4 reserved, bits 5-7 must be 0
	db 0x8e    ; 32-bit interrupt gate
	dw 0       ; offset 16-31
................................ snip

.ent08:	dw int_08  ; offset bits 0-15
	dw 0       ; selector
	db 0x00    ; bits 0-4 reserved, bits 5-7 must be 0
	db 0x8e    ; 32-bit interrupt gate
	dw 0       ; offset 16-31
.ent09:	dw int_09  ; offset bits 0-15
	dw 0       ; selector
	db 0x00    ; bits 0-4 reserved, bits 5-7 must be 0
	db 0x8e    ; 32-bit interrupt gate
	dw 0       ; offset 16-31
......................................... snip

.ent1F:	dw int_1F  ; offset bits 0-15
	dw 0       ; selector
	db 0x00    ; bits 0-4 reserved, bits 5-7 must be 0
	db 0x8e    ; 32-bit interrupt gate
	dw 0       ; offset 16-31
.end:
	

SEGMENT .bss	; must be .bss not _BSS to make NASM understand
ALIGN 16
bss_starts:
	resw 4096	; 8192 bytes reserved for stack+BSS
stack_ends:

; vim: set syn=nasm:

The unabridged source is available on request.

Regards,
Albert Wik

[Octocontrabass]

I am developing and testing my program under VMware ("Player", the free version). I am wondering if the emulation might be broken/faulty, but if that were so, why would Win98 work properly?

Considering the range of operating systems supported by VMware, it's unlikely to be broken emulation. (Especially since Windows 98 works correctly, but that's a discussion for elsewhere!)

Code: Select all

stosw

I don't see you clearing the direction flag anywhere. (It's especially important in interrupt handlers.)

Code: Select all

in al,70h  ; disable NMI

Port 0x70 is not readable.

Code: Select all

out 70h,al

Writes to port 0x70 must always be followed by a read or write to port 0x71.

Code: Select all

	shl	eax,1	; clear
	shr	eax,1   ;  paging bit

The CPU is still in real mode, so CR0.PG cannot be set.

Code: Select all

	mov	cr0,eax
mov ax, 10h  ; data/stack selector

Any MOV to CR0 that sets CR0.PE must be immediately followed by a far JMP or far CALL.

Code: Select all

push word 08h
push dword .pm32ent
retfd

Are you sure you're pushing the correct amount of data on the stack? I'm not! Mixing code and stack segment sizes is a bad idea if you value your sanity.

Code: Select all

	mov	cr0,eax
	lidt	[bp+BSS_SAVE_IDTR]

Any MOV to CR0 that clears CR0.PE must be performed in a 16-bit code segment, and must be immediately followed by a far JMP or far CALL. You'll need self-modifying code for this.

Code: Select all

mov cs,ax

You cannot MOV to CS.

Code: Select all

push word cs
;push word 0
push dword .exit32
retfd

Another case of possibly not pushing the correct amount of data on the stack.

Code: Select all

BITS 32
waitesc16:

Aren't you calling this routine from 16-bit code?

[alexfru]

There's a number of things that are wrong or not quite correct.
You're not clearing FLAGS.DF but using string instructions.
You're near-calling waitesc16 from 16-bit code but the subroutine is assembled for 32-bit mode.
You're loading 0xB800 into a segment register while still in protected mode.
You're not exactly following documented sequences for entering and leaving protected mode. Look up the intel/AMD documentation.
There's likely many more.

[awik]

Thanks a lot for all the ideas! Applying (most of) them, I was able to reach stage F, but not consistently.

However, there seems to be something really fishy going on: let's say I am able to reach stage 'B'. Then I edit some code *after* stage 'B', reassemble, and I am no longer able to reach stage 'B', but I get a CPU shutdown.

Also, because this code works more often with BITS 32 than BITS 16 (never worked a far as I can recall), that shows I am not successfully transitioning back to 16 bits. This is regardless of whether I use RETF or JUMP FAR.

Code: Select all

ALIGN 4
BITS 32
.exit32:
mov edi, (24*80+79)*2
mov ax, 0x0F00 + 'E'
stosw

This code never reaches stage 'B':

Code: Select all

ORG 100h
SEGMENT	_TEXT ;start=0 vstart=100h

RMMSGID_V86ALREADY EQU 0
RMMSGID_DOSRESIZE  EQU 1
RMMSGCOUNT	   EQU 2

main:
CPU 386
BITS 16
	smsw	ax
	test	ax, 1
	jnz .v86already
	;
	mov	sp, stack_ends
	mov	bp, bss_starts
	;
	mov	bx, sp
	add	bx, 15
	shr	bx, 4
	mov	ah, 4Ah
	int 21h
	jc .dosresize
	;
BSS_GDTR  EQU  2    ; align properly at odd word address
	mov	word [bp+BSS_GDTR], our_gdt.end-our_gdt-1  ; GDT upper limit
	mov	ax, cs
	xor	dx, dx
	mov	dl, ah
	mov	cl, 4
	shr	dx, cl
	shl	ax, cl
	add	[our_gdt.sel08+2], ax  ; base addr bits 0-15
	adc	[our_gdt.sel08+4], dl  ; base addr bits 16-24
	add	[our_gdt.sel10+2], ax  ; base addr bits 0-15
	adc	[our_gdt.sel10+4], dl  ; base addr bits 16-24
	mov	cx, ax  ; save
	mov	bx, dx  ;  "
	add	ax, our_gdt
	adc	dl, 0
	mov	[bp+BSS_GDTR+2], ax  ; GDT lin. addr; low word
	mov	[bp+BSS_GDTR+4], dx  ; " high word
BSS_OLD_SEG EQU 8
BSS_IDTR    EQU 0Ah  ; should be at odd word addr.
BSS_SAVE_IDTR EQU 0x12 ; likewise
BSS_SAVE_GDTR EQU 0x1A ; likewise
int3
	sgdt	[bp+BSS_SAVE_GDTR]
	sidt	[bp+BSS_SAVE_IDTR]
	mov	word [bp+BSS_IDTR], our_idt.end - our_idt - 1 ; IDT limit
	mov	ax, cx  ; restore ax
	mov	dx, bx  ;  and dx
	add	ax, our_idt
	adc	dl, 0
	mov	[bp+BSS_IDTR+2], ax
	mov	[bp+BSS_IDTR+4], dx
	mov	[bp+BSS_OLD_SEG], cs
	;
int3
mov ax,0xB800
mov es, ax
mov di, (24*80+79)*2
mov ax, 0x0F00 + 'A'
stosw
int3
	; fixup selector part of IDT entries
	mov	cx, (our_idt.end - our_idt) / 8 + 1
	mov	di, our_idt+2
.iloop:	mov	word [di], 08h  ; 08 is code segment selector.
	add	di, 8   ; advance 1 IDT entry.
	loop .iloop
call waitesc16
;in al,70h  ; disable NMI
;or al,80h
;out 70h,al
	cli
	lgdt	[bp+BSS_GDTR]
	lidt	[bp+BSS_IDTR]
	mov	eax,cr0
	or	al, 1
	mov	cr0,eax
mov ax, 10h  ; data/stack selector
mov ds, ax
movzx esp,sp
mov ss, ax
add al, 8	; 18h = video selector
mov es, ax
mov di, (24*80+79)*2
mov ax, 0x0F00 + 'B'
stosw

Regarding the lack of CLD, well, it doesn't matter as long as I initialise (E)DI, and do only a single STOSW before again initialising (E)DI. That is true of most uses of STOSW. In the interrupt handlers, where I use two STOSWs in a row, I added a CLD.

-Albert.

[iansjack]

However, there seems to be something really fishy going on: let's say I am able to reach stage 'B'. Then I edit some code *after* stage 'B', reassemble, and I am no longer able to reach stage 'B', but I get a CPU shutdown.

That is often a sign that you are not loading all of your code. Are you sure you are reading the correct number of sectors?

Regarding the lack of CLD, well, it doesn't matter as long as I initialise (E)DI, and do only a single STOSW before again initialising (E)DI. That is true of most uses of STOSW. In the interrupt handlers, where I use two STOSWs in a row, I added a CLD.

It's very bad practice to rely on "that's OK' to avoid a small amount of work. It's all to easy to overlook the case where "it's not OK". Initialize everything that needs to be in a known state, even if you think it doesn't matter. Just do it - it's only one extra instruction (and means that you don't need to do it for special cases - so really it's no extra instructions). Assuming that memory locations are zero is another common assumption that leads to peculiar errors.

BTW - the very last thing that you should suppose is that there is a bug in your tools, especially something as long-established as VirtualBox.

[awik]

However, there seems to be something really fishy going on: let's say I am able to reach stage 'B'. Then I edit some code *after* stage 'B', reassemble, and I am no longer able to reach stage 'B', but I get a CPU shutdown.

That is often a sign that you are not loading all of your code. Are you sure you are reading the correct number of sectors?

Reading the correct number of sectors? What are you referring to? Something, beyond the program, is definitely wrong if DOS does not load the whole program file before passing control to it. I'm not writing a boot sector but an ordinary .COM-"format" binary executable.

Regarding the lack of CLD, well, it doesn't matter as long as I initialise (E)DI, and do only a single STOSW before again initialising (E)DI. That is true of most uses of STOSW. In the interrupt handlers, where I use two STOSWs in a row, I added a CLD.

It's very bad practice to rely on "that's OK' to avoid a small amount of work. It's all to easy to overlook the case where "it's not OK". Initialize everything that needs to be in a known state, even if you think it doesn't matter. Just do it - it's only one extra instruction (and means that you don't need to do it for special cases - so really it's no extra instructions).

Well, I suppose I agree.

BTW - the very last thing that you should suppose is that there is a bug in your tools, especially something as long-established as VirtualBox.

I agree on that too, but it's hard to avoid considering this issue given how my program is behaving (see above, about later code influencing earlier code).

-Albert.

[alexfru]

Can you sprinkle "jmp $" around, that is, after each stosw (or maybe even in more places) to see how far you really get without resetting and without losing the screen contents to the reset?

Another thought I had was w.r.t. the DOS segment resizing. If you're running low on DOS memory such that your .COM program doesn't get a full 64KB segment, you may be setting SP too high. You could simply remove the resizing for now.

Yet another one, .bss is typically all zeroes. But the way you write the code and assemble it does not guarantee that. Any assumption of there being all zeroes is a mistake.

[iansjack]

Sorry, I didn't realize you were actually running the program within DOS. I've no idea how setting up a new GDT and IDT within a DOS program would affect system stability, but I wouldn't expect it to be good. What happens to - for example - a DOS timer interrupt when you have changed the interrupt table I can't imagine.

[awik]

Can you sprinkle "jmp $" around, that is, after each stosw (or maybe even in more places) to see how far you really get without resetting and without losing the screen contents to the reset?

I tried this. At first, I was getting all the way to stage 'D'. Then, after I placed a "jmp $" after the stage 'E' debug output, I no longer got even as far as to 'B' (got a reset), even though I had previously verified that the program was getting all the way to 'D'! This illustrates my whole problem with this program. Later code appears to affect earlier code. How?

Another thought I had was w.r.t. the DOS segment resizing. If you're running low on DOS memory such that your .COM program doesn't get a full 64KB segment, you may be setting SP too high. You could simply remove the resizing for now.

There is over half a megabyte free memory. But, I can try it.

Yet another one, .bss is typically all zeroes. But the way you write the code and assemble it does not guarantee that. Any assumption of there being all zeroes is a mistake.

I am not knowingly depending on any (BSS/stack) memory being zeroed. If I do, I don't know how or where.

I attached the (complete) source code, in its current revision (which resets before stage 'B') to this post. I was not allowed to upload the .COM file, so I put it on Google Drive; you can get it from this URL:
https://drive.google.com/file/d/162OvFv ... sp=sharing

It would be interesting to know if:
(a) you get the identical .COM file from assembling the source code with NASM, and
(b) how far (what stage; see lower right corner of screen) the program runs on your system (metal or virtual).

-Albert.

[PeterX]

It would be interesting to know if:
(a) you get the identical .COM file from assembling the source code with NASM, and
(b) how far (what stage; see lower right corner of screen) the program runs on your system (metal or virtual).

(a) Yes, my NASM output is identical to your .COM file.
(b) On DosBox 0.74-3 (on my Manjaro Linux) I get an 'A' at the lower right corner.

Greetings
Peter

[sj95126]

BTW - the very last thing that you should suppose is that there is a bug in your tools, especially something as long-established as VirtualBox.

I don't know that I'd agree with "very last thing". I once lost an hour banging my head against the wall because of this:

viewtopic.php?f=1&t=28879&start=0&hilit=tss+bochs

Six years later, Bochs still hasn't fixed that bug.

[iansjack]

Six years later, Bochs still hasn't fixed that bug.

It sounds as if the Bochs developers don't think it is a bug.

[sj95126]

Six years later, Bochs still hasn't fixed that bug.

It sounds as if the Bochs developers don't think it is a bug.

Their bug database still lists it as open - if they disagreed with the assessment, they should close it. Besides, since "32-bit TSS" is impossible in long mode, there's no arguing it's a bug.

[awik]

(a) Yes, my NASM output is identical to your .COM file.
(b) On DosBox 0.74-3 (on my Manjaro Linux) I get an 'A' at the lower right corner.

Thanks.

(b) OK, then I think we can rule out a virtualisation bug. It seems unlikely that VMware and DosBox would be broken in the exact same way (ie. I get an 'A' too).

(a) Then it's probably not NASM's fault either.

-Albert.

[PeterX]

Maybe I don't understand things correctly, but doesn't DOS handle the stack by itself? So why change SP at the start of the .COM program?

Greetings
Peter