This adds some new Makefile commands:
build_saturn_toolchain: Downloads GCCSH, and builds two docker
containers. One container is binutils for SuperH, and the other has
Dosemu.
build_saturn: Copies GCCSH, the source code, and asm into the build
directory and runs the GCCSH via Dosemu in the docker container.
Everything is kept in the same directory since it's hard to use Dosemu
otherwise.
check_saturn: Dumps the object files to binary using the binutils Docker
container, then checks the hashes.
diff_saturn: Compares the binaries and outputs a diff to
build/saturn/$FILENAME-diff.txt. Used like FILENAME=GAME.PRG make
diff_saturn.
I've added the source for game.c and t_bat.c. I've replaced one of the
asm functions in t_bat.c to show that it's possible to match simple
functions. I'm not able to generate linker scripts yet so functions that
rely on symbols from other overlays generally can't be matched yet.
This workflow is not all that clean so I'm open to ideas on improving
it. I tried using various versions of
https://github.com/decompals/old-gcc to try to get a native compiler but
couldn't get a matching build. I'm not 100% sure that this version of
GCCSH is correct but initial results seem promising.
As of right now, it's not possible to run this in CI since the dosemu
container changes the USER and Github won't let you write to disk if you
do that.
https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user
This PR does some initial integration work for splitting the Saturn
version. It adds T_BAT.PRG (Bat overlay) and GAME.PRG (similar to
DRA.BIN). These are extracted to asm/saturn/* and src/saturn/*. Right
now there's no attempt to compile. I haven't been able to figure out the
issues with sotn-disk so this requires pre-extracted files in
disks/saturn. Something like this is able to do it:
```
bchunk saturn.bin saturn.cue saturn.iso
7z x saturn.iso
```
The Saturn version has the code split up differently so I think putting
it in a separate folder to begin with makes sense. For example the
Random function is in GAME.PRG rather than in the stage overlays.
There's also an Alucard overlay rather than it being included in
GAME.PRG. See here for some comparisons:
https://github.com/Xeeynamo/sotn-decomp/wiki/Saturn-Matching
I didn't attempt to install Rust as part of the project setup like with
Go.
---------
Co-authored-by: sozud <sozud@users.noreply.github.com>
Solves the issue mentioned in discord - When you `cp` into expected, and
expected does not exist, the CONTENTS of build get copied into the
newly-created `expected` directory. This PR solves this by running
`mkdir -p expected` first (-p causes mkdir to not error if `expected`
already exists). Then, when `cp` runs, `expected` will always exist,
thus `build` properly gets copied into it.
Thanks to @MottZilla research I was able to extract the spritesheets of
Richter as PNGs in conjunction with the original palette from
`F_GAME2.BIN`. When the binaries are built, the PNGs are recompiled back
into binary.
In case of modding, it is possible to modify the sprite size to
accommodate bigger or smaller sprites. Although it is not possible to
modify the existing palette as currently we have no way to extract and
rebuild `F_GAME2.BIN`. You would have to modify the palette via hex
yourself. The file `config/splat.us.ric.yaml` shows in which offset the
palette is located. Just for reference, the colour format for the
palette is RGBA5551. It is important that edited PNGs has 16 colours
otherwise the build will fail.
The `padding` field is required to reconstruct some left-over / junk
data that is not part of the data sprite. For the sake of modding, the
`padding` field can be whatever.
I am not sure if `RIC.BIN` pointers can be relocated. If that is the
case you might get a black screen when playing with Richter. It should
be easily fixable though.
The objective is to separate the data that is usually written into `asm/*/data` into separate files. Those will initially be binary files.
There is also an utility that allows to decompress compressed data. The decompressed data is currently not read as we are missing a compression algorithm that matches the original one. I tried writing one in the past: it worked, it re-created similar files but sadly not the same ones. The decompression algorithm is there to allow to do some data mining and understand what the data is and how it is used.
