Compileable version of Alien Breed 3D II - The Killing Grounds

[Karlos]

Ok, results in.
Changing "vanilla" chipmem up to 8MB results in various guru on startup. Setting the 32-bit chip to 16 MB (smallest increment possible) results in success.

I assume the issue is that, at least with my mod, the game needs more than 8MB and it wants it to be MEMF_CHIP for some reason.

[trixster]

Originally Posted by Karlos

The 32-bit chip memory setting in UAE is confusing. How does it differ from the regular chip memory? It seems I can set them independently. Is it just the addressable range? Traditional chip ram can be set to 8MB (without a sex and free beer jumper emulation) but the 32-bit one goes way higher...

Chip ram in 1200, CD32, 3000 and 4000 is 32bit, whereas in the other machines it will be 16bit. So perhaps this setting is for that?

[Karlos]

I don't think so. In all the versions of UAE I'm familiar with, the chip ram value has always been "width independent". I believe 32-bit in this context is the address size as you can configure up to 1GB of it. The original chip RAM has an 8MB ceiling due to its location in the memory map.

[trixster]

Ah, ok, interesting

[Karlos]

I've recorded a play through with the latest binary. I've adjusted the emulation speed so that the game is still playable without the animations being in octuple time...

[ Show youtube player ]

[Karlos]

Not sure what happened to the audio in level 2 but it was the video capture not the game.

[TCD]

Originally Posted by Karlos

I've recorded a play through with the latest binary. I've adjusted the emulation speed so that the game is still playable without the animations being in octuple time...

[ Show youtube player ]

That looks amazing

[Karlos]

I've found the game crashes when going under water ..

[Karlos]

Once is a random event, twice a coincidence, thrice a bug report ..

[Karlos]

@pipper

Pretty sure there is a buffer overrun from the 320 width when being submerged. I've raised a bug report. It may be a duplicate of the issue you note in level C.

[pipper]

I have checked the various places where memory is dynamically being allocated. Only sound effects and music should end up in chipmem.

Also, I'm running in a WinUAE environment... it puzzles me why it won't work on other people's setup...

[Karlos]

Please check your UAE RAM configuration. When it works for me it's only because I've set this mysterious new class of 32-bit (addressable, not width) ChipRAM to 16MB. If this is set to zero, I get the crash on startup no matter what the FastRAM is set to. The game shouldn't need more than the 2MB of chip ram that was standard with AGA.

[paraj]

pipper, maybe you could share the exact configuration you're using with WinUAE (uae file)? I haven't kept up, but around the time of page 2 I could build the source locally and it worked with a hastily built 030 WinUAE setup, but now neither the locally built version nor the last "hires" you provided work. (Fell free to ignore, this is just to help in case it can narrow down the problem).

[Karlos]

@paraj - try changing your UAE configuration for RAM to include at least 16MB of "32-bit Chip RAM" and try again.

I suspect something in the latest build process results in unrealistic chip memory requirements.

[pipper]

The '-sd' linker option did not what I thought it does and caused all data and bss sections to be placed into chipmem. I removed it.
Though I'm still puzzled how this would cause massive chipmem requirements.

[Karlos]

BSS sections typically only contain the required allocation data length in the executable. You don't know how much memory it's going to use at runtime without inspecting it. I suspect there are lots of fixed sized buffers and things allocated "globally" using bss.

[phx]

Originally Posted by pipper

The '-sd' linker option did not what I thought it does and caused all data and bss sections to be placed into chipmem.

What did you expect it to do?

I'm not sure what linker we are talking about, but usually a linker option like -sc would merge all code sections, regardless of their name and attributes. -sd, on the other hand, would merge all data and bss sections, while making sure that the data sections are merged first, followed by all bss sections in memory, to allow a huge data-bss section, where only the data-part is written to disk.

Both have in common that the memory attributes of all these sections have to be merged as well. Which means, when only a single input section has the Chip-RAM attribute, then the resulting big small-code/data section has to inherit it.

[Karlos]

Originally Posted by pipper

I can wholeheartedly recommend Bebbo's GCC Toolchain (vasm/vlink come along with it)
https://github.com/bebbo/amiga-gcc

The great thing about it is that it comes with the Amiga NDK and various library headers pre-installed from Aminet. So no searching and manual installation of quite a few libraries. You can start developing amiga stuff out of the box.

Install the prerequisites (described in the README)
Then build the toolchain

make all all-sdk PREFIX=/home/<user>/amiga-gcc-out -j <n>

Then set your path there

export PATH=~/amiga-gcc-out/bin/:$PATH

And you're off to the races!

"amiga-gcc" is actually a meta-repository that ties in various other repos (gcc and binutils, libnix etc) and contains scripts to patch and format the NDK/SDK for GCC use.

On a regular basis you'll want to update it

git pull origin
make update PREFIX=/home/<user>/amiga-gcc-out 
make clean clean-prefix PREFIX=/home/<user>/amiga-gcc-out 
make all all-sdk PREFIX=/home/<user>/amiga-gcc-out -j <n>

If you find bugs with it, raise an issue on GitHub, Bebbo is usually very responsive.

Thanks for this. Going to build this in my lunch break!

I've found the cross compiler build didn't like -j4, but seems to be working fine in single threaded mode...

[Karlos]

I've built the toolchain and have been able to build the hires binary. I've updated my fork so that it has the updated makefile that removes the -sd switch. However I still get the dependency on chip rather than fast ram. Experimentally I removed the -sc switch too, and furthermore in my local branch I've replaced all MEMF_ANY with MEMF_FAST.

Yet it still crashes unless i add 16MB of the 32-bit addressable chip memory. Not sure what gives.

[paraj]

Did a "git bisect" and before commit 18ddef04d57001fb (system friendly rendering of menu) it worked for me with a plain 3.1 install and just running "hires" from the startup-sequence. 030FPU+JIT+32MB+KS3.1. Just get a black screen and pressing the cursor keys + enter randomly crashes it (sometimes). Setpatch / stack 1000000 doesn't make a difference, neither does the 16MB chip thing (so maybe it's a different issue).