DisplayAlert asm not working on Kickstart 1.3

[hop]

This simple DisplayAlert assembly language program does not display the alert on stock A500 KS1.3 in WinUAE. It works as expected on stock A1200 3.1.

	INCLUDE "intuition/intuition.i"	; RECOVERY_ALERT

	INCLUDE "lvo/exec_lib.i"
	INCLUDE "lvo/intuition_lib.i"	; _LVODisplayAlert

	SECTION code,code

	; Open intuition.library
	movea.l	4.w,a6			; ExecBase
	lea	intuitionName(pc),a1	
	moveq	#0,d0			; any version
	jsr	_LVOOpenLibrary(a6)
	tst.l	d0
	beq.b	.exit
	movea.l	d0,a6			; n.b. library's base address must be in A6 to call a system function

	move.l	#RECOVERY_ALERT,d0	; AlertNumber
	lea	string(pc),a0
	move.w	#28,d1			; Height
	jsr	_LVODisplayAlert(a6)

	; close intuition.library
	movea.l	a6,a1
	movea.l	4.w,a6
	jsr	_LVOCloseLibrary(a6)

.exit	rts

intuitionName	dc.b	"intuition.library",0
		EVEN
string		dc.w	16				; x pos in pixels (word)
		dc.b	16				; y pos in pixels (byte)
		dc.b	"Hello world!",0		; null-terminated string
		dc.b	0				; continuation byte = 0 means no more lines

Building with

vasmm68k_mot -Fhunk -kick1hunks -I%NDK%\Include_I -o displayalert.o -no-opt -wfail displayalert.s
vlink -bamigahunk -L%NDK%\lib -lamiga -o displayalert displayalert.o

I've tried debugging in WinUAE, and the DisplayAlert call just seems to return immediately. I tried stepping in but got hopelessly lost.

I wrote the equivalent code in C, built using vbcc (vc +kick13 -lauto) and it runs on A500 just fine.

Attached binary in case it is of use. Built using vasm 1.9a. vlink V0.17a. NDK 3.2 Release 4. Building on PC.

Thanks for any ideas - I can't figure this out.

EDIT: I have tried linking against the vbcc\targets\m68k-kick13\lib\amiga.lib instead of the NDK lib but that didn't help.

[Galahad/FLT]

I would change your height from move.w #28,d0 to moveq #28,d0, just incase there is something in the Highword in D1 before you use it.

[a/b]

Yup, that's why it doesn't work.

[jotd]

Good web-debugging Galahad!

[alkis]

Also, you can ommit linking with amiga.lib since you don't use anything from the library.

[Galahad/FLT]

Originally Posted by jotd

Good web-debugging Galahad!

I'm here all week \o/

[hop]

Thanks but unfortunately setting height (D1) as a longword with moveq or move.l has not fixed it for me. It's documented as a word Param but I guess that could also be a mistake. The executable is being launched as the first thing in the startup-sequence.

[thomas]

I assembled your code on my machine with an installed vbcc using the command line

vc -nostdlib alert.asm -o alert

and it worked at first try. Had to remove the INCLUDE directions and replace them by EQU because I don't have these include files, though.

Then I used D68k to disassemble both programs. Apparently in your load module the last dc.b 0 is cut off.

I'd suspect a bug in your version vasm.

yours:

D68k V2.0.8 MC68000-68060,MC68881/82,MC68851 Disassembler
Copyright 26.11.95 by Denis Ahrens

00000001 400ABBB4 00000040 00000054 401FE30C 00000001 00000001 00000000

					SECTION "",CODE       ;000 000084

000000	2C78 0004			MOVEA.L	$0004,A6
000004	43FA 002C			LEA	intuitionName(PC),A1
000008	7000				MOVEQ	#$00,D0
00000A	4EAE FDD8			JSR	-$0228(A6)
00000E	4A80				TST.L	D0
000010	671E				BEQ.B	L000001
000012	2C40				MOVEA.L	D0,A6
000014	203C 0000 0000			MOVE.L	#$00000000,D0
00001A	41FA 0028			LEA	string(PC),A0
00001E	323C 001C			MOVE.W	#$001C,D1
000022	4EAE FFA6			JSR	-$005A(A6)
000026	224E				MOVEA.L	A6,A1
000028	2C78 0004			MOVEA.L	$0004,A6
00002C	4EAE FE62			JSR	-$019E(A6)
				L000001:
000030	4E75				RTS

				intuitionName:
000032	696E 7475			dc.l	"intu"
000036	6974 696F			dc.l	"itio"
00003A	6E2E 6C69			dc.l	"n.li"
00003E	6272 6172			dc.l	"brar"
000042	7900				dc.w	$7900		;"y "
				string:
000044	0010 1048			dc.l	$00101048	;"   H"
000048	656C 6C6F			dc.l	"ello"
00004C	2077 6F72			dc.l	" wor"
000050	6C64 2100			dc.l	$6C642100	;"ld! "

mine:

D68k V2.0.8 MC68000-68060,MC68881/82,MC68851 Disassembler
Copyright 26.11.95 by Denis Ahrens

00000001 400A9BBC 00000040 00000050 401FE30C 00000003 00000003 00000000

					SECTION "",CODE       ;000 000080

000000	2C78 0004			MOVEA.L	$0004,A6
000004	43FA 0026			LEA	L000002(PC),A1
000008	7000				MOVEQ	#$00,D0
00000A	4EAE FDD8			JSR	-$0228(A6)
00000E	4A80				TST.L	D0
000010	6718				BEQ.B	L000001
000012	2C40				MOVEA.L	D0,A6
000014	7000				MOVEQ	#$00,D0
000016	41FA 0026			LEA	L000003(PC),A0
00001A	721C				MOVEQ	#$1C,D1
00001C	4EAE FFA6			JSR	-$005A(A6)
000020	224E				MOVEA.L	A6,A1
000022	2C78 0004			MOVEA.L	$0004,A6
000026	4EAE FE62			JSR	-$019E(A6)
				L000001:
00002A	4E75				RTS

				L000002:
00002C	696E 7475			dc.l	"intu"
000030	6974 696F			dc.l	"itio"
000034	6E2E 6C69			dc.l	"n.li"
000038	6272 6172			dc.l	"brar"
00003C	7900				dc.w	$7900		;"y "
				L000003:
00003E	0010 1048			dc.l	$00101048	;"   H"
000042	656C 6C6F			dc.l	"ello"
000046	2077 6F72			dc.l	" wor"
00004A	6C64 2100			dc.l	$6C642100	;"ld! "
00004E	0000				dc.w	$0000

[hop]

Originally Posted by thomas

Apparently in your load module the last dc.b 0 is cut off. I'd suspect a bug in your version vasm.

Thanks very much. This has caught me out before. To use the KS1.3 loader vlink requires the -Z option to prevent it from stripping trailling zero bytes.

Unfortunately this doesn't seem to fix the issue in this case. I've tried adding a dummy non-zero byte at the end and that hasn't worked either. Will investigate.

[a/b]

Last zero is not "missing", it's in the combined code+bss hunk (22 longwords total, 21 actual, 1 bss) that KS1.3 doesn't clear.
When I loaded your exe into memory and changed the problematic move.w to moveq/nop it worked fine (because I was lucky with memory being empty), but I didn't check the hunk structure. The problem is that the final byte, explicitely set to zero, is put together with extra 3 byte padding (hunk size is in longowords) into BSS. KS1.3 doesn't clear that, KS2.0+ does.
I'm using asm-one/pro and the code is generated properly, only required fix is setting d1 as longword. Try adding 3 zeroes (to round up your hunk size manually), or better yet a non-zero byte after the last zero (cont. byte).

edit: Just remembered that phx said vasm default mode is KS2.0 and any trailing zeroes are converted to BSS. Adding extras zeroes won't help, add a non-zero at the end and it should work.
Not sure why -Z doesn't work. Examine the hunk structure (load exe as raw binary), there should be no combined CODE+BSS if linked for KS1.3 (hunk size should be $16=22 longwords in both cases).

[hop]

Ah. It is working sorry. I was launching the wrong exe after the -Z / non-zero-end-byte change (repro case vs real code). Thanks for the support.

I must try to remember this V34 LoadSeg + default vlink stripping combo gotcha!

Originally Posted by Galahad/FLT

I would change your height from move.w #28,d0 to moveq #28,d0, just incase there is something in the Highword in D1 before you use it.

It does actually look like DisplayAlert requires the full longword to be written though. Maintaining the hunk structure by using move.w vs moveq + nop proves this. It looks like the signature changed the type of height from word to ULONG at some point

BOOL DisplayAlert( ULONG alertNumber, CONST_STRPTR string, ULONG height );

So there were two issues here. Thanks

[Galahad/FLT]

Hurrah, we got there

[phx]

Originally Posted by a/b

Just remembered that phx said vasm default mode is KS2.0 and any trailing zeroes are converted to BSS.

Yes and no. vasm prefers 2.0 hunks and needs

-kick1hunks

to be really compatible to Kickstart 1.x. But, unlike vlink, vasm does not remove trailing zeroes unless requested by

-databss

, when writing an executable instead of an object (

-Fhunkexe

).

Work on vasm started 20 years ago and vlink is even 25 years old. At that time I couldn't imagine anybody would write new programs for Kickstart 1.x again. This might explain the presets. Although I admit that it is better design to enable additional features with options, instead of having to disable them.

Not sure why -Z doesn't work.

This is the vlink option to not remove trailing zeroes.