WHDLOAD Slave Problems running above 68000

[field3d]

Hello. I have problems building one slave of a program. The behavior is crazy. All the test were made in WINUAE:

1.-If I run the floppy directly without the whdload slave. A single df0: floppy boot, it works and runs from 68000,68010,68020,68030, anything.
2.-If I enter the workbench and I run from the whdload slave it will rock only in 68000. If I enter in 68010 or above it runs the game but I have very bad behavior in keyboard crashes, delays among other things.

Why runs only with 68000 the whdload after compile? What can be wrong in the code? Exist something to force only to run in 68000 no matter if you run in 68010 or above? Or what is suggested here? Maybe can be added something in the whdload to fix? The strange is as I said the Floppy original runs very good in all 6800 and above and fine as DF0: floppy boot. But running from the workbench via the whdload slave compiled only works and perfect but in 68000, above 68000 keyboard and other problems come up. I have maybe 3 weeks figuring and I can’t find any solution.

This is the slave how I’m building:

		INCDIR	include/
		INCLUDE	whdload.i
		INCLUDE	whdmacros.i
		INCLUDE	lvo/dos.i

		IFD BARFLY
		OUTPUT	"xxx.slave"
		BOPT	O+			;enable optimizing
		BOPT	OG+			;enable optimizing
		BOPT	ODd-			;disable mul optimizing
		BOPT	ODe-			;disable mul optimizing
		BOPT	w4-			;disable 64k warnings
		BOPT	wo-			;disable warnings
		SUPER				;disable supervisor warnings
		DOSCMD	"WDateT:date"
		ENDC

;============================================================================

;CHIP_ONLY

    IFD CHIP_ONLY
;;CHIPMEMSIZE	= $180000
;;FASTMEMSIZE	= $0000
    ELSE
;;CHIPMEMSIZE	= $80000
;;FASTMEMSIZE	= $100000
    ENDC
CHIPMEMSIZE	= 1024*1024 ; $80000	;size of chip memory
FASTMEMSIZE	= 0 ;$80000	;size of fast memory


;CHIPMEMSIZE	= 1024*1024 ; $80000	;size of chip memory
;FASTMEMSIZE	= 0 ;$80000	;size of fast memory

NUMDRIVES	= 2
WPDRIVES	= %0000

BLACKSCREEN
;DEBUG
;DISKSONBOOT
DOSASSIGN
HDINIT
HRTMON
IOCACHE		= 10000
;MEMFREE	= $100
;NEEDFPU
SETPATCH
SNOOPFS			;trace filesystem handler
BOOTDOS
;CBDOSLOADSEG

;============================================================================


slv_Version	= 18
slv_Flags	= WHDLF_NoError|WHDLF_Examine|WHDLF_EmulTrap|WHDLF_NoDivZero
slv_keyexit	= $59	;


;============================================================================

	INCLUDE	whdload/kick13.s

;============================================================================

_disk1  	dc.b    "floppy1",0  


DECL_VERSION:MACRO
	dc.b	"2.0"
	IFD BARFLY
		dc.b	" "
		INCBIN	"T:date"
	ENDC
	IFD	DATETIME
		dc.b	" "
		incbin	datetime
	ENDC
	ENDM
	dc.b	"$","VER: slave "
	DECL_VERSION
	dc.b	0

slv_name		dc.b	"xxx"
    IFD CHIP_ONLY
    dc.b    "(DEBUG/CHIP ONLY)"
    ENDC
    dc.b    0
slv_copy		dc.b	"1xxx",0
slv_info		dc.b	"xxx",10,10
		dc.b	"xxx ",10,10

        ;DECL_VERSION
		dc.b	0
slv_CurrentDir	dc.b	"data",0
_program	      dc.b	"PRG",0
_args		dc.b	10
_args_end	dc.b	0
_dosbase	dc.l	0
	IFGE slv_Version-17
slv_config	
	ENDC
		EVEN

;============================================================================

I assigned the disk1 dir as:

		lea	_disk1(pc),a0		;Assigns
		;;lea _dir1(pc),a1 
		sub.l	a1,a1
		bsr	_dos_assign

And I load the _program like this:

		lea	_program(pc),a0
		move.l	a0,d1
		jsr	(_LVOLoadSeg,a6)
		move.l	 d0,d7			;D7 = segment
		beq	.end			;file not found

		move.l	d7,a1
		add.l	a1,a1
		add.l	a1,a1
		lea	(_args,pc),a0
		move.l	(4,a7),d0		
		sub.l	#5*4,d0	
		movem.l	d0/d7/a2/a6,-(a7)
		moveq	#_args_end-_args,d0
		
		jsr	(4,a1)
	
		movem.l	(a7)+,d1/d7/a2/a6
	
	
		move.l	d7,d1
		jsr	(_LVOUnLoadSeg,a6)

[jotd]

tey noautovec or vbrmove see if it runs with those tooltypes for starters.

Disassemble the PRG file (a must do at any rate) and identify keyboard handling routine that may need rework/replacement. Check INT3/VBL routines too.

[DJ Mike]

Which Kickstart ROM and graphics chipset have you set in WinUAE?

[field3d]

Thank you for the fast response.

@DJ Mike. I use a lot to test.From 68000 to 68030. Kickstarts I used the 2.04, 3.1. Workbench 3.9 and 2.1. In all places work if I use 68000 no matter the workbench version or kickstart.

@jotd the noautovec and vbrmove didn’t help same issue. I dissembled the code and I detected the main loop it stays stuck or buggy. For example, this is the keyboard routine:

This loop routine pass always:

000549b2 4279 0005 49da           clr.w $000549da [0000]
000549b8 4eb9 0005 4a1e           jsr $00054a1e
000549be 4a79 0005 42fc           tst.w $000542fc [0000]
000549c4 6602                     bne.b #$02 == $000549c8 (F)
000549c6 60ea                     bra.b #$ea == $000549b2 (T)
000549c8 4a68 001e                tst.w (a0,$001e) == $00054540 [0000]
000549cc 6706                     beq.b #$06 == $000549d4 (T)
000549ce 4eb9 0005 49dc           jsr $000549dc
000549d4 4cdf 7fff                movem.l (a7)+,d0-d7/a0-a6
000549d8 4e75                     rts  == $00000008

This is the routine of the ‘jsr $00054a1e’:

00054a1e 48e7 fcfe                movem.l d0-d5/a0-a6,-(a7)
00054a22 3039 0005 42c6           move.w $000542c6 [0000],d0
00054a28 3200                     move.w d0,d1
00054a2a 671e                     beq.b #$1e == $00054a4a (T)
00054a2c b07c 0068                cmp.w #$0068,d0
00054a30 6c18                     bge.b #$18 == $00054a4a (T)
00054a32 2a7c 0005 4a5c           movea.l #$00054a5c,a5
00054a38 e541                     asl.w #$02,d1
00054a3a 2a75 1000                movea.l (a5,d1.w,$00) == $00005c58 [00000000],a5
00054a3e 670a                     beq.b #$0a == $00054a4a (T)
00054a40 4e95                     jsr (a5)
00054a42 4a79 0005 42da           tst.w $000542da [0080]
00054a48 67f8                     beq.b #$f8 == $00054a42 (T)
00054a4a 4cdf 7f3f                movem.l (a7)+,d0-d5/a0-a6
00054a4e 4e75                     rts  == $000549be

I detected that the keyboard and mouse are detected/controlled with these routines:

0005401e 48e7 fc00                movem.l d0-d5,-(a7)
00054022 4240                     clr.w d0
00054024 1039 00bf ec01           move.b $00bfec01,d0
0005402a e218                     ror.b #$01,d0
0005402c 0a00 00ff                eor.b #$ff,d0
00054030 3239 0005 42d8           move.w $000542d8 [00ff],d1
00054036 b041                     cmp.w d1,d0
00054038 6746                     beq.b #$46 == $00054080 (T)
0005403a 33c0 0005 42d8           move.w d0,$000542d8 [00ff]
00054040 13fc 0041 00bf ee01      move.b #$41,$00bfee01
00054048 343c 0100                move.w #$0100,d2
0005404c 5342                     subq.w #$01,d2
0005404e 66fc                     bne.b #$fc == $0005404c (F)
00054050 13fc 0001 00bf ee01      move.b #$01,$00bfee01
00054058 33c0 0005 42c6           move.w d0,$000542c6 [0000]
0005405e b07c 0045                cmp.w #$0045,d0
00054062 6608                     bne.b #$08 == $0005406c (F)
00054064 33fc 0001 0005 42be      move.w #$0001,$000542be [0000]
0005406c 3200                     move.w d0,d1
0005406e 0241 0080                and.w #$0080,d1
00054072 33c1 0005 42da           move.w d1,$000542da [0080]
00054078 6706                     beq.b #$06 == $00054080 (T)
0005407a 4279 0005 42c6           clr.w $000542c6 [0000]
00054080 1039 00df f00b           move.b $00dff00b,d0
00054086 1239 0005 42d2           move.b $000542d2 [b8],d1
0005408c 13c0 0005 42d2           move.b d0,$000542d2 [b8]
00054092 9001                     sub.b d1,d0
00054094 6714                     beq.b #$14 == $000540aa (T)
00054096 6d0a                     blt.b #$0a == $000540a2 (F)
00054098 0679 0001 0005 42d6      add.w #$0001,$000542d6 [0000]
000540a0 6008                     bra.b #$08 == $000540aa (T)
000540a2 0479 0001 0005 42d6      sub.w #$0001,$000542d6 [0000]
000540aa 1039 00df f00a           move.b $00dff00a,d0
000540b0 1239 0005 42d0           move.b $000542d0 [fb],d1
000540b6 13c0 0005 42d0           move.b d0,$000542d0 [fb]
000540bc 9001                     sub.b d1,d0
000540be 6714                     beq.b #$14 == $000540d4 (T)
000540c0 6d0a                     blt.b #$0a == $000540cc (F)
000540c2 0679 0001 0005 42d4      add.w #$0001,$000542d4 [0000]
000540ca 6008                     bra.b #$08 == $000540d4 (T)
000540cc 0479 0001 0005 42d4      sub.w #$0001,$000542d4 [0000]
000540d4 3039 0005 42ea           move.w $000542ea [0005],d0
000540da 5240                     addq.w #$01,d0
000540dc 33c0 0005 42ea           move.w d0,$000542ea [0005]
000540e2 b07c 0005                cmp.w #$0005,d0
000540e6 6f00 002e                ble.w #$002e == $00054116 (T)
000540ea 33fc 0000 0005 42ea      move.w #$0000,$000542ea [0005]
000540f2 3039 0005 42e8           move.w $000542e8 [0009],d0
000540f8 5240                     addq.w #$01,d0
000540fa 33c0 0005 42e8           move.w d0,$000542e8 [0009]
00054100 b07c 000a                cmp.w #$000a,d0
00054104 6d10                     blt.b #$10 == $00054116 (F)
00054106 33fc 0000 0005 42e8      move.w #$0000,$000542e8 [0009]
0005410e 0679 0001 0005 42e6      add.w #$0001,$000542e6 [001b]
00054116 4e71                     nop
00054118 4cdf 003f                movem.l (a7)+,d0-d5
0005411c 4e73                     rte  == $000548be

That are some routines that cause you type something and gets stuck. I don’t see something special. In 68000 zero problems everywhere. Or if I boot from the main Floppy also works, but here directly from floppy it will boot even if is 68010+. Just the whdload asks always to be 68000 I don’t understand this bevahior.

[paraj]

The keyboard routine is not great (busy loop at $00054048) and it only acks if key changed (though maybe not a problem). Use keyboard.s in the whdload sources or adapt it for your needs.

[field3d]

Hello @paraj. It’s good to see you. I see with use keyboard.s. You mean replace all that routine with that one? Or exactly what means use keyboard.s? I noted that this routine I copied also controls mouse some events.

[paraj]

As always things depend, yes, the code you shared does other things that need to be preserved (including updating the game specific variables where the key is stored.

You first need to understand how the keyboard interface works (at least superficially): http://amigadev.elowar.com/read/ADCD.../node0198.html (though note that you should use >85ms delay, the whdload keyboard.s routine uses 200us). A busy wait for >3 raster lines usually suffices.

"keyboard.s" is a bit heavy-weight in that it assumes it can install a level 2 handler and use CIA-A timer A. If it can, and won't be disturbed that's fine, otherwise you need to adopt the code in a different way.

[field3d]

Ok @paraj I see. But in the code to start making preliminary tests what routine I should attack to see if replaced by keyboard.s? I think this one to replace?

00054024 1039 00bf ec01           move.b $00bfec01,d0
0005402a e218                     ror.b #$01,d0
0005402c 0a00 00ff                eor.b #$ff,d0

I guess here is where it takes the keyboard key?

And yes I detect something is interrupting with the whdload slave because I made the test to also boot as DISKSONBOOT feature and it boots and runs perfectly but the same keyboard types not work. Then only the problem is when you load through the SLAVE. If you run the program without any salve stand alone it runs very nice everywhere. Then I assume something is interfering in the WDHLOAD code slave and the program.


Also I note that bra that always is using clr.w $000549da to after go to a jsr then return to bra again, this is rare because the routine for keyboard I mentioned is called as before this loop and where I see is stuck is in the loop searching for something. Sometimes if I press a key it can take 5 minutes to see the key in screen is like a delay caused by something is waiting or doing that loop.

Honestly this loop i don’t know what it is doing or waiting because here is not involved the keyboard press, that event of keyboard press already happened here and the loop is after the key press:

000549b2 4279 0005 49da           clr.w $000549da [0000]
000549b8 4eb9 0005 4a1e           jsr $00054a1e
000549be 4a79 0005 42fc           tst.w $000542fc [0000]
000549c4 6602                     bne.b #$02 == $000549c8 (F)
000549c6 60ea                     bra.b #$ea == $000549b2 (T)

That loop is what causing me headache.

[DJ Mike]

@field3d: From a cursory glance at routine $54a1e (the one being JSR'ed in your quoted code in the last post), I believe it:

- reads the keyboard key currently stored in $542c6 (set by the interrupt routine you quoted starting at $5401e - I assume this is a ports interrupt but it has zero indication of this due to a lack of clearing INTREQ/$dff09c, which is troubling in itself!)
- checks if the key code is greater than or equal to $68 (and skips to the end of the routine if it is - i.e. we only care about key codes <$68)
- uses that key as the basis for a jump table that starts at $54a5c - you can see it loading a5 with the jump offset (a5,d1), then it does "jsr (a5)" to call it
- waits for $542da to be non-zero before continuing. No idea what this variable is from your quoted code above but often when I see tst/beq loops like that they are for VBL waits

I would guess that $542fc is expected to contain some result that each of the jumptable routines is supposed to provide on finishing, but I can't be too sure about much else without seeing more of the game code.

Something worth investigating is whether the game is starting up with all the interrupts and DMA pre-enabled that it expects to be. Sometimes I have found game code doesn't set DMA/interrupts correctly and just inherits whatever the operating system happened to set them to when booting the game. WHDLoad clears these more aggressively, which means a game sometimes fails to start as a result (perhaps due to a VBlank interrupt not being serviced). You can work this out quite easily with WinUAE by using the debugger and comparing what the DMAENA/INTENA registers are set to when you boot the game from disk, versus what they're set to within your WHDL slave.

If you are missing DMA/interrupts in your WHDL slave you can simply enable them near the top of your patch before jumping into the game code.

By the way, the interrupt routine $5401e really needs investigating too:
- it fails to check which interrupt reason caused the exception by reading INTREQR. However that's not necessarily an issue if there is only one type of interrupt that can cause the routine to run.
- way more concerning: it fails to clear INTREQ, which means whatever interrupt causes that exception to run can keep calling it over and over spuriously. It's possible that the game is somehow doing this elsewhere, but it is really not good practice to exit an interrupt without acknowledging/clearing the reason it occurred.

[field3d]

@DJ Mike. Good information. Well about the registers I took a photo of the registers at the moment. The photos with green letters is when boots from floppy outside the whdload and that works 100%. And the photos with red letters is when is not working and is running through the whdload slave:

https://freeimage.host/i/dVLBW0B
https://freeimage.host/i/dVLBEWx
https://freeimage.host/i/dVLBVfV
https://freeimage.host/i/dVLBGiQ

Any abnormality or if that is not the information to search?

[DJ Mike]

Only difference I can see is that COPPER interrupt is enabled - but in the "not working" versions. I'm doubtful that is the cause though.

I can't see anything to go on from those screenshots I'm afraid.

Requires a deeper dive into where the code is getting stuck. If as you say it is getting stuck when you type something, I'm strongly suspicious of that interrupt code not clearing the interrupts, but that is only a hunch.

You're definitely sure setting NOVBRMOVE on WHDLoad startup params did not fix the problem? (I ask because JOTD quoted the opposite - 'VBRMOVE' - but actually what you want to do is make sure WHDLoad does *not* move VBR).

[jotd]

at this point you can share the full data package (slave source + game data) and I'll have a look.

[field3d]

@DJ Mike and @JOTD indeed it worked now!. The tool type it was NOVBRMOVE I was entering VBRMOVE.

Now I have 2 questions about this?

1.-Can be placed that NOVBRMOVE inside the assembly code of the SLAVE? I entered that thing in the icon info only.

2.-And disabling this has to do with the exit key? I tried to exit with the regular key but it didn’t respond after the NOVBRMOVE.

What is suggested here?

But it worked and strong disable that NOVBRMOVE.

[jotd]

NOVBRMOVE cannot be left as is. Your program is certainly reading the VBR somewhere if cpu > 68000. You have to disable it and make the code believe that VBR is 0, else it will poke in whdload vector base and will do harm.

Disassemble the code in 68020 mode with IRA and look for VBR accesses. I bet you'll find a couple of them.