Yet another set of questionable C reimplementations of master.lib functions to
waste my time. And half of them, including z_text_(v)putsa, aren't even called
anywhere.
Fuck TH02 and above and their bizarre assembly code that indeed appears to be,
uh, playfully "optimized" in the most inadequate of places, far away from the
innermost loop. It's ALWAYS just these one or two instructions I just can't
fucking get out of the C compiler, which lead to the conclusion that these
functions must have either been first compiled to assembly, then "fine-tuned"
and then linked into the executable…
… or I'm really just missing some obscure compiler setting.
At least with TH01, you can tell that the source language must have undeniably
been C++, and the decompilation is a breeze.
The same function appears unused in TH02's MAINE.EXE. Separate commit because
this was painful enough and we can link the C version into FUUIN.EXE right
now.
Well, duh, of course, we *can* do this in order to allow decompilation to be
started at the end (not the beginning) of any segment. In fact, if we hadn't
done this, we would have had to start by moving _TEXT out to libraries....
This took long enough, so we're not covering the COM files right now. Like, I
can't even tell how you're supposed to work around the forced word alignment
for the _TEXT segment. Guess we'll just have to decompile all of these in one
go, just like we did with ZUNSOFT.COM.
Also, it really seems as if we're merely trading one ugly workaround for
another in our quest for identical binaries.
I've looked at every openly available piece of PC-98 documentation, and there
don't seem to be any official names for the individual planes. The closest
thing I could find was the description at
http://island.geocities.jp/cklouch/column/pc98bas/pc98disphw2.htm
explaining that they represent the blue, red, green, and brightness component
when using the default PC-98 palette. However, these planes correspond to
nothing else but the 4 individual bits of the final index into the color
palette, and you can assign any color to every single palette slot. Therefore,
it's merely a convention that your own palettes don't have to follow (and in
Touhou, they don't).
Nevertheless, there doesn't seem to be an alternative, and the Neko Project II
source code uses the same B/R/G/E convention, so I'll go with that as well.
Thanks to the LOCALS directive, we do need to break compatibility to TASM at
one point after all. This is the rest we can reasonably change to get at least
through JWasm's first pass without errors while maintaining compatibility to
TASM.
Includes:
* the OPTION syntax to switch in and out of floating-point emulation mode
* REP CMPSB → REPE CMPSB
* Hacks for two 80-byte short jumps
* lack of support for floating-point stupidity ♥
as well as other issues that I covered in previous commits and overlooked in
some files.
For 32-bit immediate values, PUSH by itself is enough. For everything else,
PUSHD works in both TASM and JWasm.
Also, could it be...? Could we actually move to JWasm without breaking the
build in TASM at all?
Yup, packfiles finally proved that we really have a different set of changes
to master.lib in every game. Also, there are bound to be more of these game-
specific small changes to otherwise identical code in ZUN's own code.
And hey, no need to define that value in the build scripts anymore.
(I've also considered just copying modified versions into the individual game
subdirectories, but it's not too nice to expect people to diff them in order
to actually understand why these copies exist and where the changes actually
are.)
> introduce a new macro to halve the lines of a far function pointer
assignment, hoping that this commit will end up deleting more lines than it
adds, because TH03 has lots of those
> oh wait, these games mainly use near function pointers
> unearth even more new functions in the process
Seriously, how many more functions are still hidden in this codebase? And all
that just because IDA was not smart enough to begin with.
(Damn, the other commit prepared for today is not getting done, why does IDA
have to be so terrible...!)
Anyway, here's a small consistency edit instead.
> randomly google "PC-98 ライブラリ"
> 3rd hit: http://www.vector.co.jp/soft/dos/prog/se037608.html
> Oh look, it's the mystery code at the beginning of the TH01 executables!
This library also has dedicated support for transparency, which is used in the
Konngara fight (BOSS8_D*.GRP) and which we couldn't edit during the
development of the static English patches.
But of course, ZUN just had to change the format magic in order to make it
seem unique.
I guess this marks the final demystification of how segment declarations work
and how they are compiled. However, it only really makes sense for anything
outside the TEXT segment, like these floating-point functions. As long as the
slices aren't immediately next to each other, it would still be annoying to
have segment declarations inside of them, since we'd have to copy-paste these
declarations around every INCLUDE directive...
Finally - and there was indeed no way around switching to JWlink, as ALINK
v1.6 refuses to link the TH01 executables with a nondescript "Undefined base
seg" message once nec_fpinit.asm is included.
So that's the - admittedly rather weird - solution to the problem that has
been plaguing this project ever since the beginning of the reduction step.
Without any 32-bit dummy segments in the compiled object files, more linkers
will be able to build this project, one of them being JWlink
(http://sourceforge.net/projects/jwlink/).
Still can't rename dseg to _DATA though, as TASM stupidly refuses to accept
any ALIGN directives above a segment's alignment attribute value. TH01's
floating-point data slices already require larger alignments, and we're very
likely to have even more of those in the future.
Also, we're finally defining the Borland C++ model symbols directly in the
code, rather than in my unpublished build batch files. :)
Mostly moving spurious null bytes, which are actually supposed to denote
alignment, into their associated slices, but also prettying up some of the
very first slices.
Well, we have to start reducing this mess somewhere. The actual reduced
initialization code I've been preparing still fails to compile, and the data
is shared with a number of other components anyway, so...
There's also the PC-98-specific nec_delay. Which means that the inclusion of
this function into the games was *ding* entirely pointless.
Man, compilers sucked in the early 90s.
Especially annoying if that happens in the middle of a Shift-JIS multi-byte
sequence, like in those two instances in TH02's OP.EXE. Also, making up for
the lack of string analysis during the dumping process of TH05's MAIN.EXE.
Looks like the 'pal98 grb' string was merely copy-pasted from the respal
module and isn't actually used by the function, which means that we don't have
to work around a naming collision after all.
OK, *that's* the last piece of C++ crud shared across all main executables.
According to the object in the library file though, it seems to include one
more dword named
__DestructorCountPtr
in the BSS segment. Neither games nor the runtime itself seem to use it, and
as a consequence, it doesn't even seem to be included in the games' BSS
segments, given that they all end with the symbols of xx.cpp...
Neither is this one. Also, interesting how IDA didn't identify the function in
one third of the cases.
[Binary change] Order of 2 relocations in TH03's MAINL.EXE, TH04's MAIN.EXE
and MAINE.EXE, and TH05's MAINE.EXE.
nmlgc