Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/build32b.bat

42 lines
1.3 KiB
Batchfile
Raw Normal View History

Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
@echo off
echo Running the first, 32-bit part of the ReC98 build process.
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files 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.
2015-02-19 06:46:36 +00:00
set ReC98_ASM=tasm32 /m /mx /kh32768 /t /ilibs\master.lib\
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
Rename all code segments to names that Turbo C++ would generate 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....
2015-02-21 11:47:24 +00:00
del /S *.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
for /L %%i in (1,1,5) do mkdir bin\th0%%i 2>NUL
%ReC98_ASM% 1>NUL 2>NUL
if errorlevel 9009 goto no_tasm32
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files 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.
2015-02-19 06:46:36 +00:00
%ReC98_ASM% th01_op.asm bin\th01\op.obj
%ReC98_ASM% th01_reiiden.asm bin\th01\reiiden.obj
%ReC98_ASM% th01_fuuin.asm bin\th01\fuuin.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
%ReC98_ASM% th02_zuninit.asm bin\th02\zuninit.obj
%ReC98_ASM% th02_op.asm bin\th02\op.obj
%ReC98_ASM% th02_main.asm bin\th02\main.obj
%ReC98_ASM% th02_maine.asm bin\th02\maine.obj
[th03] Identify ZUNSP.COM as a rebrand of Promisence Soft's SPRITE16.COM driver Which was actually found out by @m1yur1 last year, who thankfully tweeted this in reference to ReC98: https://twitter.com/m1yur1/status/1018855232371998720 Thanks a lot! But what makes this more than a piece of trivia is the fact that the StormySpace release actually *was* bundled with documentation. Shoutout to the Neo Kobe PC-98 collection for preserving the original release! This should now greatly simplify any RE efforts related to TH03's INT 42h calls. (Not *trivialize*, because there's still all this EGC hardware to be understood…) And sure, you *were* allowed to use this driver in your own game, but replacing the copyright with your own isn't exactly the nicest thing to do… That now makes three library programmers that ZUN didn't credit. Makes me wonder what makes M. Kajihara so special. Probably the fact that Touhou has always been about the music for ZUN, first and foremost. Part of P0056, funded by rosenrose and [Anonymous].
2019-11-01 08:41:15 +00:00
%ReC98_ASM% /DTHIEF libs\sprite16\sprite16.asm bin\th03\zunsp.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
%ReC98_ASM% th03_op.asm bin\th03\op.obj
%ReC98_ASM% th03_main.asm bin\th03\main.obj
%ReC98_ASM% th03_mainl.asm bin\th03\mainl.obj
%ReC98_ASM% th04_op.asm bin\th04\op.obj
%ReC98_ASM% th04_main.asm bin\th04\main.obj
%ReC98_ASM% th04_maine.asm bin\th04\maine.obj
%ReC98_ASM% th05_op.asm bin\th05\op.obj
%ReC98_ASM% th05_main.asm bin\th05\main.obj
%ReC98_ASM% th05_maine.asm bin\th05\maine.obj
goto eof
:no_tasm32
echo Could not find TASM32.
echo Please make sure that the BIN directory of Turbo Assembler 5.0 is in your PATH.
goto eof
:eof
Finally use standard segment names everywhere And I guess we just have to ignore and disable that segment alignment warning for TH01. It's not like this changes anything in the binary.
2015-02-18 11:07:37 +00:00
echo -------------------------------------------------------------------------------