Ambermoon open source remake in progress

[Pyrdacor]

Do you have the same issue with the original version 1.07?

[SquawkBox]

You mean German version 1.08 ? 1.07 is missing from your repository. I searched the Zone!, the only 1.07 version available is unpacked.

which gives :

Unable to load ram:: Error code 212

[Pyrdacor]

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

Try English 1.07 or German 1.05 from there please.

[SquawkBox]

German v1.05 fails in the same way German v1.08 fails (plus a briefly seen "not valid Disk A image" IIRC). As per English v1.05, I had to convert it to ADF first as the Gotek doesn't read DMS. Used your preformatted J Disk as Save Disk, loads just fine :

[dlfrsilver]

Originally Posted by Pyrdacor

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

Try English 1.07 or German 1.05 from there please.

Mmhh...... I made a set of ADF of v1.10. It runs on A1200, but the A500 version simply fails. I always get a guru screen.

Whatever the RAM i use : 512kb+512kb or 1Mb of chip ram.

[dlfrsilver]

Originally Posted by SquawkBox

You mean German version 1.08 ? 1.07 is missing from your repository. I searched the Zone!, the only 1.07 version available is unpacked.

which gives :

Unable to load ram:: Error code 212

Please also note that this game requires lots of ram (the A500 version requires 1.5mb of ram once hard drive installed, and need 1mb of chip minimum from disk).

[SquawkBox]

Originally Posted by dlfrsilver

Please also note that this game need 1mb of chip minimum from disk.

which my machine bears, else I could not manage to load the English version from Thalion webshrine (check the picture, said version loads entirely with no error from the set of DMS's). I also said earlier on that I wasn't interested in playing the game from HD. If I reduce by half chip mem thanks to the middle switch at the back of my machine, here is the result :

[dlfrsilver]

Originally Posted by Pyrdacor

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

Try English 1.07 or German 1.05 from there please.

Pyrdacor, i made different tests, and i have found where the problem comes from.

Basically, v1.07 from Thalion webshrine works fine on A500 512 chip +512 fast.

Version v1.08,v1.09,v1.10 just fail on A500 configuration.

I did a simple test : load the program from disk with disk A v1.07, then use disks B to I from the v1.10 set containing your data files modified.

It crash no matter what. So, there are 2 news, one good and one bad.

The good news is that all the modifications you did to fix the game data files are OK, no problem there.

The bad news is that you changed the data files (at least text data files like xMap_Texts.amb for instance) structures.

How did i noticed that ? Simple : I use the automatic data files ressourcer that CFOU, my partner in crime made for me in 2013 when i did the translation in french of the game.

The data files are crippled, because the ressourcer once i process the files from files 'xMap_Texts.amb' for example, outputs all the texts with the first character and the last character chopped off.

The game parser is very unforgiving on that matter. Squawkbox fails to get to the screen where the grand father's text is displayed.

I seem to remember that you shorten some bytes in the text data files, but the parser seems to not like it......

What should we do now ?

[Pyrdacor]

I will investigate this soon and work on a fix for the A500.

[dlfrsilver]

Originally Posted by Pyrdacor

I will investigate this soon and work on a fix for the A500.

The fix consist of fixing every text data files in the game.

here is the structure of text banks inside archives xMap_texts.amb :

Let's take file 0B6.amb from 1Map_texts.amb in my french version or v1.07 :

Offset $0000 : 0001 (number of banks inside the data file)
Offset $0002 : 0059 (length of the text bank)
Offset $0003 : 20 (separator byte between header above and the text bank)
Offset $0004-0059 : (text bank content + custom characters and encoding)
Offset $005A-005E : (ending text bytes, present in all data files : '20 00 20 00')

now here is what the same data file looks like when ressourced :

Offset $0000 : 0001 (number of banks inside the data file)
Offset $0002 : 0059 (length of the text bank)
Offset $0003 : 20 (removed start text byte)
Offset $0004-0059 : (text bank content + custom characters and encoding)
Offset $005A-005E : (removed ending text bytes, present originally in all data files : '20 00 20 00')

the start byte '20' that make the separation between the header and text start is missing, as well as the ending bytes '20 00 20 00'.

This difference is the only existing between v1.07 data files and the versions above (v1.08 - v1.10) that are crashing.

The crash doesn't appear when using the program v1.10 with v1.07 data files.

[SquawkBox]

Originally Posted by dlfrsilver

Basically, v1.07 from Thalion webshrine works fine on A500 512 chip +512 fast.

It also works fine from A500 1024 (1 MB) chip, with the added bonus that it requires 20 less memory when using exclusively chip mem (says the requester from the last picture I took, after I deliberately reduced total mem to 512 chip). Not a tangible bonus, but anyway.
The additional 512 from my machine is not actual chip mem. The trick is, it's been soldered in a way it is recognized as such by the system AFAIK.

@Pyrdacor
I'll playtest your fixed version as soon as it is ready, we can get in touch by PM, whatever suits your purposes.

[Pyrdacor]

As the text file fixes didn't avoid the crash I believe the added data might have exceeded the 1MB ram space. Some fixes required some additional data. Even though they were small it might have been enough to exceed the 1MB margin.

Maybe one of you can play with 1.07 and leave grandpa's house. Then switch to 1.08 or 1.10 and continue with the savestate. Then the world maps should be loaded which in general have less changes and only very few texts. If this works, the changes (mostly to indoor maps and dungeons) might indeed have reached the 1MB limit.

I will also try to reproduce this soon. I am back at my computer on Thursday.

[dlfrsilver]

Originally Posted by Pyrdacor

As the text file fixes didn't avoid the crash I believe the added data might have exceeded the 1MB ram space. Some fixes required some additional data. Even though they were small it might have been enough to exceed the 1MB margin.

Maybe one of you can play with 1.07 and leave grandpa's house. Then switch to 1.08 or 1.10 and continue with the savestate. Then the world maps should be loaded which in general have less changes and only very few texts. If this works, the changes (mostly to indoor maps and dungeons) might indeed have reached the 1MB limit.

I will also try to reproduce this soon. I am back at my computer on Thursday.

I have found something else. the A500 version works on A600 with 2mb of chip.

This means no A500 OCS, only A500 ECS with 1,5mb of chip or A600 2Mb.

[alexh]

Looks like this could be down to the implementation of LOB depacker in AM2_BLT and Pyradcor's re-implementation of LOB packer.

If you don't use re-compressed sub-files then it works. (At least in the very small set of tests that I tried).

[Don_Adan]

If this is compressor problem. Why Pyrdacor dont use original LOB packer from Atari ST? If i remember right, Ambermoon data are packed and crypted.

[alexh]

Originally Posted by Don_Adan

If this is compressor problem. Why Pyrdacor dont use original LOB packer from Atari ST? If i remember right, Ambermoon data are packed and crypted.

Many years ago I gave the AtariST version to dlfrsilver and he said it was incompatible. Perhaps a later/earlier version than the one used on Ambermoon?

[dlfrsilver]

Originally Posted by alexh

Many years ago I gave the AtariST version to dlfrsilver and he said it was incompatible. Perhaps a later/earlier version than the one used on Ambermoon?

I did multiple tries on crunching the files. It never worked.

Don Adan gave me the lob packer v3.7.

[Don_Adan]

Originally Posted by dlfrsilver

I did multiple tries on crunching the files. It never worked.

Don Adan gave me the lob packer v3.7

No, this is compatible. Only one format LOB 1-2 (if i remember right is incompatible, when i compared depackers). But Ambermoon used standard LOB 1-5 compression, if i remember right. At first you must decode and rip LOB files (use Track2File). And later you can depack. and repack with LOB 3.7. and compare if are identical. To be working with original game exe you must CRYPT new packed file.

[dlfrsilver]

Originally Posted by Don_Adan

No, this is compatible. Only one format LOB 1-2 (if i remember right is incompatible, when i compared depackers). But Ambermoon used standard LOB 1-5 compression, if i remember right. At first you must decode and rip LOB files (use Track2File). And later you can depack. and repack with LOB 3.7. and compare if are identical. To be working with original game exe you must CRYPT new packed file.

If i use F2 inside LOB packer 3.7, it encodes the file to LOB format.

However, you talk about CRYPTING the new packed file. How was it done ?

and sorry to say this, but the LOB packer v3.7 doesn't allow automatic packing of multiple files. This means that for the file of archive 2Map_texts.amb, you need to pack each file individually (what a nightmare ! )

[dlfrsilver]

Originally Posted by Don_Adan

No, this is compatible. Only one format LOB 1-2 (if i remember right is incompatible, when i compared depackers). But Ambermoon used standard LOB 1-5 compression, if i remember right. At first you must decode and rip LOB files (use Track2File). And later you can depack. and repack with LOB 3.7. and compare if are identical. To be working with original game exe you must CRYPT new packed file.

I have finally found the compression type !!!

It's the MSS (F6) choice in the LOB packer v3.7 !

WHAT A MESS !