Ambermoon WHDLoad

[alexh]

Ambermoon for the Amiga is being developed once again (in conjunction with Ambermoon.net for other platforms) to add new content and fix remaining bugs.

The code has been re-sourced using Ghidra and can be re-assembled. It has had various functional bugs patched and has been changed to be able to be built as a single binary (down from 4 separate binaries).

I'm just taking a look at what AmigaOS/CPU compatibility bugs the WHDload script for Ambermoon tries to fix.

It tries to patch the following files

Ambermoon_intro
Ambermoon_extro
Fantasy_intro

The notes say "fixed access fault due vbr access"

Can a WHDLoad "expert" describe to be what I am reading in the slave source?

_pde4en_fantasy_x PL_START
		PL_W	$fe,$4e71	;skip getting vbr
		PL_P	$ff2,_intack
		PL_P	$1010,_intack20
		PL_END

Is it trying to replaces the WORD (16-bits) at file-offset $fe (within the depacked Fantasy_intro file) with the value $4e71 (NOP)?

If I depack the original file Fantasy_intro and look at file-offset $fe it has the opcode $4e75 (RTS) which is not what I was expecting.

So I am I reading the slave ASM wrong?

[Don_Adan]

I dont coded long time slave for WHDload, but this is offset to first hunk start code, not to begining of exe file. Then you must skip some extra bytes, minimum 36 bytes, if this is exe with only one hunk.

[alexh]

Good call

[Wepl]

Yes, the given offset is the offset of the relocated binary. If you load it in ReSource or process via IRA it will show you this offset.
There is a short description of the patch commands here: https://whdload.de/docs/autodoc.html#resload_Patch

[alexh]

Originally Posted by Wepl

Yes, the given offset is the offset of the relocated binary. If you load it in ReSource or process via IRA it will show you this offset.

Thanks I'll try that.

Another question: Are all the "skip getting vbr" patches a consequence of using WHDload? They are not compatibility fixes but necessary to run WHDload without the NoVBRMove option?

By default WHDLoad moves the vector table using the VBR (Vector Base Register) to a different memory location. This has the advantage that the installed program cannot change the vector table, which increases security and stability of WHDLoad greatly. Some installed programs will not correctly work with a moved vector table. The reason for this may be that the installed program uses processor exceptions or is doing other strange stuff.

I don't quite know what Ambermoon is doing when it reads the VBR, I think it is part of it's 68000 / 68010+ detection routine.

[Wepl]

Originally Posted by alexh

Another question: Are all the "skip getting vbr" patches a consequence of using WHDload? They are not compatibility fixes but necessary to run WHDload without the NoVBRMove option?

Yes, running under WHDLoad it should not read/change the vbr.

Originally Posted by alexh

I don't quite know what Ambermoon is doing when it reads the VBR, I think it is part of it's 68000 / 68010+ detection routine.

Maybe it's setting interrupt vectors directly?