Ambermoon debug help

[alexh]

Hello everyone.

The game Ambermoon initially released in 1993 got a spiritual new owner in the form of Pyrdacor who chose to maintain the Amiga version while he was developing his C# remake.

Part of his Amiga work was to move to a universal binary for 68000 and accelerated Amiga's (previously Ambermoon had two, one for 68000 - AM2_BLT and one for accelerators - AM2_CPU) *AND* localisation (texts were relocated from inside the binary to text files which are loaded in at runtime)

Everything works great if you use a pre-installed HDD image. And I *think* it works if you insert the disks in workbench and HDD install using the icon. But if you boot from FD (ADF / real disks) it crashes.

Pyrdacor has run out of time to spend on the Amiga fixes and so we are asking the community if you can take a quick look and see if you can spot what is wrong? This will almost certainly require some Amiga coding / debugging knowledge.

The last Amiga version is v1.19 and the ADF files are available here :

https://github.com/Pyrdacor/Ambermoo...h_1.19_adf.zip
https://github.com/Pyrdacor/Ambermoo...n_1.19_adf.zip
https://github.com/Pyrdacor/Ambermoo...h_1.19_adf.zip

(It should not matter which localisation that you use)

Should you want access to the source code to a particular file (e.g. Ambermoon, Ambermoon_Install, AM2_CPU) just ask and we can make it available as all files are now rebuilt from "re-sourced" code with limited comments.

The bug report says "boot loader" but it does not mean disk boot sector. Ambermoon disk A is a AmigaDOS disk with s/startup-sequence which calls the Ambermoon intro with the switch BOOT1 followed by Ambermoon_install

Version >NIL: exec.library 36
if WARN
	System/SetMap gb
endif
Ambermoon BOOT1
if WARN
	System/SetMap gb
	dir >NIL: RAM:
	Ambermoon_install
else
	EndCLI
endif

[paraj]

Downloaded ambermoon_english_1.07_adf.zip, started WinUAE 5.2.0b4 w/ quickstart A1200 (basic) with "Best compatability" and 4 drives enabled. After a bunch of disk swapping (in turbo mode) I get to the start of the game. When is it supposed to crash?

[alexh]

Thanks for taking an interest.

My bad, I wasn't clear with my instructions.

Please try the latest : ambermoon_english_1.19_adf.zip

v1.07 is the original release from Thalion. That doesn't crash. (But it doesn't have any bugfixes or localisation changes)

FYI the source code to Ambermoon_Install from v1.19 is available here :

https://github.com/Pyrdacor/Ambermoo...moon_install.s

[paraj]

Yeah sorry, my bad, didn't notice the version thing See the crash now. Which version is the last one that works? I can try that myself, but if you already know..

[alexh]

I don't know for sure but I imagine it was v1.13

v1.14 was the big change that introduced a single binary.

Changes in 1.14
===============

- Merged AM2_BLIT into AM2_CPU
- Extracted all in-game texts to Text.amb
- Extracted all item data to Objects.amb
- Extracted all button graphics to Button_graphics
- Renamed Monster_char_data.amb to Monster_char.amb
- Renamed Dictionary.english to Dict.amb
- Added loader for the extracted files

v1.17 "fixed" Ambermoon_Install which hadn't been updated for the new files introduced in v1.14.

Changes in 1.17
===============
- Fixed the installer

I suspect the changes made to the Ambermoon_install.s for v1.17 are the cause of the crash but I don't know for sure.

I *believe* prior to v1.17 it used the original file from Thalion (which hadn't worked correctly since v1.13). Pyrdacor disassembled it and modified it. I can ask if he has the original disassembly so you can diff his changes.

It might be available on the Ghidra server

https://gitlab.com/ambermoon/research/-/wikis/ghidra

[paraj]

I've made a super quick whdload slave for testing. Just rename ADF images A/B and J to disk.1/disk.2 and disk.3, and place them next to slave.

With MMU it reports invalid long read pretty early - something to look into.
W/O it gets further and crashes with illegal instruction in AM2_CPU.

If you make a crash dump all of memory can be examined and analyzed more thoroughly.

[paraj]

Looked a bit more. Function at $27768 (in IRA parlance) in AM2_CPU is doing something very suspicious with low memory. It's copying stuff to the interrupt vector table that doesn't seem correct. In particular it installs a Level1 handler that seems bogus which causes a crash a bit later when a SOFT int is triggered.

Someone who knows the souce more should be able to go from there. Not going to reverse engineer a >300KB executable to figure out what it should be doing.

[alexh]

Thank you. The full source of AM2_CPU is available on Ghidra server. I'll pass this info to Pyrdacor who might know what it's about.

I wonder if it's where he added loading of the texts from file that previously were compiled into the exe?

[alexh]

Here is some preliminary feedback from Pyrdacor. I *think* he's not 100% sure if he has used the value $27768 correctly?

Originally Posted by pyrdacor

Ghidra starts at offset $21f000, so if the mentioned offset of $27768 is from the base address it would be $246768 which is exactly FUN_ShowWindow.

If Paraj has Ghidra he can also have a look at Nico's server. Everyone has read-only access to it.

https://ghidra.nicode.net/

Here is AM2_CPU.s (see zone) the full ASM. You can just search for "FUN_ShowWindow:"

Couldn't find anything suspicious in this function. The error might have been introduced by my Ghidra exporter. Can't rule that out.

Here is the diff of the ASM file from before the unification up to the last version. (see zone)

FUN_ShowWindow:
	movem.l A6/A5/A4/A3/A2/A1/A0/D7/D6/D5/D4/D3/D2/D1/D0,-(SP)
	jsr FUN_ResetSomethingHistory
	jsr FUN_ResetMouseStateHistory
	movea.l DAT_CurrentWindowDefinitionPointer,A1
	movea.l A1,A2 ; A2 points to the window
			; definition header.
	lea ($0036,A1),A1 ; A1 points to the function list
			; which is located after the
			; action data header.
	cmpa.l #DAT_DataStackPointer-4,A1 ; Some kind of invalid address?
			; Or maybe not enough space?
	beq.w LAB_00246838
	movea.l A0,A3
	movea.l A1,A4
	tst.b DAT_002887e2
	beq.b LAB_002467a0
	move.b #$01,(A4)
	bra.b LAB_002467a2

[paraj]

Yes, got ghidra setup, and that makes it much easier.

Crash is caused by FUN_ShowWindow since DAT_CurrentWindowDefinitionPointer is 0 at this point.

FUN_Init calls FUN_Resources which tries to load files from disk G, and wants to open a window asking for that disk, but this is before FUN_OpenDefaultWindow_Maybe has been called to initialize DAT_CurrentWindowDefinitionPointer (and probably some other stuff).

However it's not as simple as just having disk G inserted or reordering the lines in FUN_Init to open default window first (which I've tried).

Seems like at least early "ask for disk change" logic got broken by dynamic language support. Crash can probably be replicated in HD version by temporarily removing some of the needed files.

[alexh]

Many thanks. Pyrdacor [thinks he] now understands the crash. The data in two files text.amb and objects.amb used to be compiled into AM2_CPU executable. The changes Pyrdacor made for easy localisation mean these texts are now in two files that are now loaded from disk when you launch AM2_CPU. This loading happens much earlier on than any normal file loading, before certain things are initialised.

The solution Pyrdacor is going to try is to squeeze these files (currently on disk G?) onto whichever disk is in the drive at the time AM2_CPU needs to load these files (Disk A?) so as to not have to open a disk request dialogue.

[dlfrsilver]

Originally Posted by alexh

Many thanks. Pyrdacor now understands the crash. The data in two files text.amb and objects.amb used to be compiled into AM2_CPU executable. The changes Pyrdacor made for easy localisation mean these texts are now in two files that are now loaded from disk when you launch AM2_CPU. This loading happens much earlier on than any normal file loading, before certain things are initialised.

The solution Pyrdacor is going to try is to squeeze these files (currently on disk G?) onto whichever disk is in the drive at the time AM2_CPU needs to load these files (Disk A?) so as to not have to open a disk request dialogue.

Ok, let's see what Pyrdacor comes with

[alexh]

Thanks to @paraj Pyrdacor has been able to find and fix the issue.

Originally Posted by pyrdacor

Sometimes a tiny error breaks everything. I used the wrong disk number for file Objects.amb It was 7 (disk G) instead of 1 (disk A) A single byte change fixed this. The 1.19 release ADF files are now fixed and re-released so that you can play it directly from floppies on your Amiga again.

FYI playing from floppy disks is not recommended but at least it is now fixed.

All languages (GB, DE & FR) updated

http://thalion.exotica.org.uk/games/...s/credits.html

or

https://github.com/Pyrdacor/Ambermoon/tree/master/Disks

[Pyrdacor]

Hi there. I just wanted to give a big thanks to Paraj. With your investigation results I could finally find the cause. In the end it was a single byte.

For each file there is also a byte which specifies the disk number. I externalized some data (texts, button graphics and item data) out of the executable into 3 new files. They are loaded when AM2_CPU is started and just copies the data into a BSS hunk. This way it was pretty easy to do all this.

But as this is done before any window setup, no window must be requested, as you mentioned. So this means that those 3 files must be on disk A where the AM2_CPU is located. I thought I placed some file on disk G by mistake but this was not the case. They were all on disk A. But for 1 of the 3 files I specified the wrong disk number in code, so that it still requested disk G at this point.

This is of course not noticeable when installing the game to HD.

So the fix was just to change the disk number for Objects.amb from 7 (disk G) to 1 (disk A).

The 1.19 release ADF files in English, German and French are updated so that it now should work again.


Thank you for your help!

[paraj]

Glad you got it working! :

Thanks for explaining the issue, now it makes sense why my attempt at fixing it didn't work.