WHDLOAD Slave Problems running above 68000

[field3d]

@jotd @paraj @DJ Mike it worked now.

Thanks @DJ Mike. Yes I removed NOVBRMOVE to test of course as @jotd anlso confirmed you can’t have it always enabled as the root problem should be fixed. But let me tell you that is incredible your tip about adding WHDLF_NoKbd worked like a charm!. It works perfect and even the exit key of whdload all is working. Thank you for the tip. That simple thing solved a complex interruption.

Thank you so much for the help now the issue was solved by adding the WHDLF_NoKbd

[DJ Mike]

Interesting. I confess I'm surprised that worked given kick13. What is the ports interrupt at $68 set to?

You should also test if quit key still works with NOVBRMOVE set, as this is helpful for users on 68000 machines.

[field3d]

@DJ Mike Yes it is interesting. And in the case of the exit key I noted many slaves not work for 68000. They work in 68010+. Is there a fix for that or you need to dig up in code and force a key from the game to force to the routines of exit key of whdload?

Note this are the actual registers now working in 68020 just for reference:

https://ibb.co/fFTmbK0
https://ibb.co/8sCQQxF

[DJ Mike]

$68 seems to be pointing at the OS ports interrupt, so I'm surprised that WHDL is interfering, but again I don't know the specifics of what it does there. If NoKbd fixes the issue then just go with that for now.

If quit key does not work when NOVBRMOVE is set then you need to intercept the key code during vertb interrupt (i.e. patch game's code) and compare with _keyexit, e.g. "cmp.b _keyexit(pc),d0" (if for example game has already put code in d0). Usually a good place to patch is where game does ror.b #1,d0 + not.b d0 (or eor.b #$ff,d0 as I can see game doing in this case), as you can check for _keyexit straight after.

[field3d]

Yes I guess. Ok now is working perfect.

Thank you

[field3d]

Hello again. I just have 2 questions more about these. Is owning perfect and in 68000 I noted that not work but is not a problem configure sending the check to a routine that cmp the bfec01 tip your value and then exit.

I have like this:

		cmp.b 	#slv_keyexit,d0
		beq	.exit

exit		pea	TDREASON_OK
		bra	.end2

.end2		move.l	(_resload),-(a7)
		add.l	#resload_Abort,(a7)
		rts

But my questions are:

1.-When exit in 68000 in some parts of the programs it does good but the memory is not freed. What I add there in the exits to release the memory or that close gracefully? For example, if I move in some parts of the game and I exit with the quit key I defined it does but the memory in the workbench is full and of course if I want to run something else I have messages that i don’t have memory available.

2.-I noted that the exit key works perfect like that but in 68000 what happens if I want to add with the QUITKEY another key and I don’t want to compile, I just want to modify via the icon and with QUITKEY, is possible? How? I noted now that only is taken the one I have in my variable “slv_keyexit” and it never will listen clearly to the QUITKEY tool type. That I thing is obvious as I’m fixing a value in the assembly code but is there a way also that is heard what I have in the tool type QUITKEY in the icon or whdload prefs?

[DJ Mike]

1) WHDLoad should free all memory on exit - you should not need to do this if you are using its built-in exit function. If there is a bug with WHDLoad freeing memory on 68000 then it probably needs reporting via Mantis.

2) Rather than #slv_keyexit, you should instead do: cmp.b _keyexit(pc),d0
This is the field from the slave structure (if you look in kick13.s you will see it defined).
WHDLoad replaces that value with the QUITKEY configured by the user when the slave starts up, so it will automatically use the right key.
What you've written at the moment only uses the constant defined in your slave source.

[field3d]

Thank you @DJ Mike. Yes it was that. I will monitor that issue of the free memory in some parts of the release happens when you exit. Just in 68000 I will check and if this is happening over and over I will report to mantis as you say.

For now I needed to add the routine of:

move.l #WHDLTAG_ATTNFLAGS_GET,-(a7)
move.l a7,a0
move.l (_resload,pc),a2
jsr (resload_Control,a2)
move.w (6,a7),d0 ;D0 = AttnFlags
lea (12,a7),a7 ;restore sp
btst #AFB_68010,d0

This to check different processors and only execut the key thing modifications for 68000 and not harm the code for 68010+.

But now all is working 100% from start to finish the slave, except that occasional issues of whdload in exit with 68000.

Thank you for the help.

[DJ Mike]

You don't need to do a processor check for _keyexit - it is fine to do it on all processors (and a good idea, in case the user decides to run with NOVBRMOVE for some reason).

[field3d]

Oh I see yes exactly you are right if user runs with such stuff the keyexit will continue working. One more thing I’m updating some slaves and I detect that most of the games tracing the BFEC01 is where keys comes usually. But some games not. Is there any other memory position different to that one to hear such events? I detect some titles don’t hear the BFEC01 or at least if I make a whole memory search for that memory position during the game progress is not found the BFEC01

[DJ Mike]

Might be accessed as an offset of an address register, e.g. ($c00,a4) where a4 = $bfe001.

[field3d]

Got it. Thank you