Once you've actually found the right syntax that makes the assembler just use
the default call type of the current memory model for both procedures (where
it's just "PROC" without anything else) and labels (where it's "LABEL PROC"),
these constants become completely unneccessary, even with TASM.
> 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.
Since DSEG is *supposed* to be aligned to a paragraph boundary, this should
have never mattered. However, JWlink seems to not obey this segment alignment
in some layer of the linking process.
This now guarantees identical builds with TLINK, ALINK and JWlink.
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.
nmlgc