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

197 lines
5.9 KiB
Makefile
Raw Normal View History

Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
# ReC98
# -----
# Makefile for the 16-bit part of the build process
[C decompilation] [th02/op] Title screen flashing animation
2015-02-21 13:13:58 +00:00
CFLAGS = -ls -Ilibs\master.lib\ -I. -Lbin\ -O -a2
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
TH01 = \zunsoft.com \op.exe \reiiden.exe \fuuin.exe
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
TH02 = \zuninit.com \zun_res.com \op.exe \main.exe \maine.exe \zun.com
TH03 = \zunsp.com \res_yume.com \op.exe \main.exe \mainl.exe \zun.com
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
TH04 = \res_huma.com \op.exe \main.exe \maine.exe
TH05 = \res_kso.com \op.exe \main.exe \maine.exe
all: th01 th02 th03 th04 th05
@echo Done. Find the executables in the bin\ subdirectory.
th01:: $(TH01:\=bin\th01\)
th02:: $(TH02:\=bin\th02\)
th03:: $(TH03:\=bin\th03\)
th04:: $(TH04:\=bin\th04\)
th05:: $(TH05:\=bin\th05\)
[Reverse-engineering] [th04/th05] HUD bar display So it's *_put(), inherited from master.lib, for everything just writing to text RAM, and *_render() for everything more involved? But what about master.lib's own graphics RAM functions like super_put()? Need to fix that inconsistency some day. Once again no decompilation, because… Part of P0033, funded by zorg.
2019-09-20 18:36:19 +00:00
{th05}.asm{bin\th05}.obj:
$(AS) /dGAME=5 $**, $@
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
# Shared TH04/TH05 assembly units
# -------------------------------
# Need to go into separate .obj directories since they will have different
# AFLAGS per game.
{th04}.asm{bin\th04}.obj:
$(AS) /dGAME=4 $**, $@
{th04}.asm{bin\th05}.obj:
$(AS) /dGAME=5 $**, $@
# -------------------------------
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
.obj.exe:
$(CC) $(CFLAGS) -ml $**
.obj.com:
tlink /t /3 $**
bin\th01\zunsoft.com: th01\zunsoft.c
[C decompilation] [th02/op] Title screen flashing animation
2015-02-21 13:13:58 +00:00
$(CC) $(CFLAGS) -mt -lt -nbin\th01\ $** masters.lib
[Decompilation] [th01] graph_printf_fx
2019-12-18 05:45:08 +00:00
bin\th01\op.exe: bin\th01\op.obj th01\op_02.c th01\op_03.c th01\op_04.c th01\op_06.cpp th01\op_08.c th01\op_10.c th01\op_11.c th01\op_12.cpp
[Decompilation] [th01] Restorable line drawing Yes, when clipping the start and end points to the screen area, ZUN uses an integer division to calculate the line slopes, rather than a floating-point one. Doesn't seem like it actually causes any incorrect lines to be drawn, though; that case is only hit in the Mima boss fight, which draws a few lines with a bottom coordinate of 400 rather than 399. It *might* also restore the wrong pixels at parts of the YuugenMagan fight, causing weird flickering, but seriously, that's an issue everywhere you look in this game. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 18:13:26 +00:00
$(CC) $(CFLAGS) -ml -3 -DGAME=1 -nbin\th01\ -eOP.EXE @&&|
[C decompilation] [th01/op] [th01/reiiden] Random resident structure stuff
2015-03-07 16:35:30 +00:00
$**
|
[C decompilation] [th01] MDRV2 calls Still missing mdrv2_resident() though, which we currently can't slot in there due to that string constant constructor syntax. :/
2015-02-21 19:45:02 +00:00
[Decompilation] [th01] master.lib resident palette function reimplementations Which store colors as GRB, as suggested by the structure's ID string. Even master.lib's own functions add an additional XCHG AH, AL instruction to get colors into and out of this format. MASTER.MAN suggests that it's some sort of standard on PC-98. It does match the order of ths hardware's palette register ports, after all. (0AAh = green, 0ACh = red, 0AEh = blue) Now we also know why __seg* wasn't used more commonly, as lamented in c8e8e98. Turbo C++ simply doesn't support a lot of arithmetic on segment pointers. And then that undecompilable far call to a function within the same segment, but inside a different translation unit… Also, thanks again to Egor for the SCOPY@ hack that debuted in 0460072. Would have probably struggled with this a lot more without that. And *then* you realize that TH01 effectively doesn't even use the resident palette. 😐 And yes, we're procrastinating the whole issue of potentially using a single translation unit for all three binaries by using a common segment name, because it *really* isn't that easy. Completes P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 15:10:00 +00:00
bin\th01\reiiden.exe: bin\th01\reiiden.obj th01\main_02.c th01\main_03.c th01\main_04.c th01\main_06.cpp th01\main_12.c th01\main_13.c th01\main_14.c th01\main_16.c
[Decompilation] [th01] Restorable line drawing Yes, when clipping the start and end points to the screen area, ZUN uses an integer division to calculate the line slopes, rather than a floating-point one. Doesn't seem like it actually causes any incorrect lines to be drawn, though; that case is only hit in the Mima boss fight, which draws a few lines with a bottom coordinate of 400 rather than 399. It *might* also restore the wrong pixels at parts of the YuugenMagan fight, causing weird flickering, but seriously, that's an issue everywhere you look in this game. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 18:13:26 +00:00
$(CC) $(CFLAGS) -ml -3 -DGAME=1 -nbin\th01\ -eREIIDEN.EXE @&&|
[C decompilation] [th01/op] [th01/reiiden] Random resident structure stuff
2015-03-07 16:35:30 +00:00
$**
|
[C decompilation] [th01] MDRV2 calls Still missing mdrv2_resident() though, which we currently can't slot in there due to that string constant constructor syntax. :/
2015-02-21 19:45:02 +00:00
[Decompilation] [th01] graph_printf_fx
2019-12-18 05:45:08 +00:00
bin\th01\fuuin.exe: bin\th01\fuuin.obj th01\fuuin_05.c th01\fuuin_06.c th01\fuuin_08.cpp th01\fuuin_09.c th01\fuuin_11.c th01\fuuin_12.c th01\fuuin_13.c
[Decompilation] [th01] Restorable line drawing Yes, when clipping the start and end points to the screen area, ZUN uses an integer division to calculate the line slopes, rather than a floating-point one. Doesn't seem like it actually causes any incorrect lines to be drawn, though; that case is only hit in the Mima boss fight, which draws a few lines with a bottom coordinate of 400 rather than 399. It *might* also restore the wrong pixels at parts of the YuugenMagan fight, causing weird flickering, but seriously, that's an issue everywhere you look in this game. Part of P0069, funded by [Anonymous] and Yanga.
2020-01-12 18:13:26 +00:00
$(CC) $(CFLAGS) -ml -3 -DGAME=1 -nbin\th01\ -eFUUIN.EXE @&&|
[C decompilation] [th01] VRAM region copy via EGC 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.
2015-02-27 22:11:47 +00:00
$**
|
[C decompilation] [th01] MDRV2 calls Still missing mdrv2_resident() though, which we currently can't slot in there due to that string constant constructor syntax. :/
2015-02-21 19:45:02 +00:00
[C decompilation] [th02] ZUN_RES.COM This, hands down, has been the single worst stretch of decompilation so far. Three extremely difficult functions that each still required inline assembly. And no, this didn't even work out with any of the optimization features in Borland C++ that aren't included in Turbo C++.
2015-09-16 03:02:29 +00:00
bin\th02\zun_res.com: th02\zun_res1.c th02\zun_res2.c
[Maintenance] Move TH02's sound functions to a separate header Oh hey, guarding declarations with complicated types via #ifdef limits the header files we additionally have to #include! Part of P0076, funded by [Anonymous] and -Tom-.
2020-02-18 18:46:34 +00:00
$(CC) $(CFLAGS) -mt -lt -Z -DGAME=2 -nbin\th02\ -eZUN_RES.COM @&&|
[C decompilation] [th02] ZUN_RES.COM This, hands down, has been the single worst stretch of decompilation so far. Three extremely difficult functions that each still required inline assembly. And no, this didn't even work out with any of the optimization features in Borland C++ that aren't included in Turbo C++.
2015-09-16 03:02:29 +00:00
$**
| masters.lib
[C decompilation] Finish TH02's OP.EXE
2015-03-16 21:35:52 +00:00
bin\th02\op.exe: th02\op_01.c bin\th02\op.obj th02\op_02_1.c th02\op_02_2.c th02\op_03.c th02\op_04.c th02\op_05.c th02\op_06.c
[C decompilation] [th02/op] Shot type selection Oh, OK, so this is what the PC-98 GRCG is all about. You call grcg_setcolor(), and that puts the PC-98 hardware in some sort of "monochromatic mode". Then, you just write your pixels into any *single* one of the 4 VRAM bitplanes. This causes the hardware to automatically write to *all* bitplanes in such a way that the final palette index for each of the 8, 16, or 32 pixels you just wrote a 1 value to will actually end up to match the color you set earlier. Don't forget to call grcg_off() at the end though, or you can't draw any non-monochromatic graphics, heh.
2015-02-25 22:05:20 +00:00
$(CC) $(CFLAGS) -ml -Z -DGAME=2 -nbin\th02\ -eOP.EXE @&&|
$**
|
[C decompilation] [th02/maine] Rotating rectangle animation Small detour into MAINE.EXE because it has all the juicy algorithms that will explain the remaining unknown members of the highscore data structure, and there's this one code segment here we need to get out of the way first.
2015-02-28 21:37:40 +00:00
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
bin\th02\main.exe: bin\th02\main.obj th02\main02_1.c th02\main02_2.c
[C decompilation] [th02] PI display
2015-03-04 03:28:16 +00:00
$(CC) $(CFLAGS) -ml -Z -DGAME=2 -nbin\th02\ -eMAIN.EXE @&&|
[C decompilation] [th02] First set of sound driver calls
2015-03-04 01:39:36 +00:00
$**
|
[C decompilation] [th02] Code segment #2 of all three executables Only one code segment left in both OP and FUUIN! its-happening.gif Yeah, that commit is way larger than I'm comfortable with, but none of these functions is particularly large or difficult to decompile (with the exception of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have their own unique functions in between the shared ones, so…
2015-03-14 22:25:50 +00:00
bin\th02\maine.exe: bin\th02\maine.obj th02\maine021.c th02\maine022.c th02\maine_03.c th02\maine_04.c th02\maine_05.c
[C decompilation] [th02/maine] Rotating rectangle animation Small detour into MAINE.EXE because it has all the juicy algorithms that will explain the remaining unknown members of the highscore data structure, and there's this one code segment here we need to get out of the way first.
2015-02-28 21:37:40 +00:00
$(CC) $(CFLAGS) -ml -3 -Z -DGAME=2 -nbin\th02\ -eMAINE.EXE @&&|
$**
|
[C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1
2015-03-03 09:20:20 +00:00
bin\th03\op.exe: bin\th03\op.obj th03\op_02.c
$(CC) $(CFLAGS) -ml -DGAME=3 -nbin\th03\ -eOP.EXE @&&|
[Decompilation] [th03] Sprite display calls Yes, decompilation, of something that was so obviously originally written in ASM. We're still left with two un-decompilable instructions here, but I'm amazed at how nicely I was able to abstract away all of the gory register details, leading to pretty clear, readable, and dare I say *portable* code?! Turbo C++ was once again pretty helpful here: • `static_cast<char>(_BX) = _AL` actually compiles into `MOV BL, AL`, as you would have intended, • and no-op assignments like _DI = _DI are optimized away, allowing us to leave them in for clarity, so that we can have all parameter assignments for the SPRITE16 display call in a single place. I love this compiler. Part of P0060, funded by Touhou Patch Center.
2019-11-22 21:25:41 +00:00
$**
|
[Decompilation] [th03] Shot update and render functions Meh, can't overload arithmetic operators that take a Subpixel without generating a needless load and store, even with -Z. But heck, slightly uglifying subpixel/subpixel arithmetic is exactly the right trade-off. Completes P0061, funded by Touhou Patch Center.
2019-12-03 21:45:08 +00:00
bin\th03\main.exe: bin\th03\main.obj th03\main_01.cpp th03\sprite16.cpp
$(CC) $(CFLAGS) -ml -Z -DGAME=3 -nbin\th03\ -eMAIN.EXE @&&|
[C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1
2015-03-03 09:20:20 +00:00
$**
|
[Reverse-engineering] [th04] Extra Stage selectability Final structure in TH04's OP.EXE! 🎉 Position independence now reached here as well. Part of P0064, funded by Touhou Patch Center.
2019-12-29 11:14:54 +00:00
bin\th04\op.exe: bin\th04\op.obj th04\op_01.cpp th04\op_02.c
[Maintenance] [th04/th05] Define a OP/MAIN/MAINE macro Seems to be the best way to handle all those implementation differences in the GENSOU.SCR functions. Part of P0063, funded by -Tom-.
2019-12-27 20:02:26 +00:00
$(CC) $(CFLAGS) -ml -DGAME=4 -DBINARY='O' -nbin\th04\ -eOP.EXE @&&|
[C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1
2015-03-03 09:20:20 +00:00
$**
|
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
bin\th04\scoreupd.obj: th04\scoreupd.asm
bin\th04\main.exe: bin\th04\main.obj bin\th04\scoreupd.obj
[Maintenance] [th04/th05] Define a OP/MAIN/MAINE macro Seems to be the best way to handle all those implementation differences in the GENSOU.SCR functions. Part of P0063, funded by -Tom-.
2019-12-27 20:02:26 +00:00
$(CC) $(CFLAGS) -ml -DGAME=4 -DBINARY='M' -nbin\th04\ -eMAIN.EXE @&&|
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
$**
|
[Reverse-engineering] [th04/th05] Player sprite area invalidation And once again, the TH05 version is un-decompilable. :/ It was pretty close this time, though, as the entire block between PUSH DI and POP DI kind of resembles a separate inlined function, in accordance with Turbo C++'s automatic backup of the DI register, as researched in 7f971a0. Except that it contains a loop, and Turbo C++ refuses to inline any function with `do`, `while`, `for`, or `goto`. If it didn't, it would have totally worked. Also, yes, C++ class methods are treated identically in this regard. Oh well. Shot type control functions next, finally! Completes P0035, funded by zorg.
2019-09-24 18:54:32 +00:00
bin\th05\player.obj: th05\player.asm
[Reverse-engineering] [th04/th05] HUD bar display So it's *_put(), inherited from master.lib, for everything just writing to text RAM, and *_render() for everything more involved? But what about master.lib's own graphics RAM functions like super_put()? Need to fix that inconsistency some day. Once again no decompilation, because… Part of P0033, funded by zorg.
2019-09-20 18:36:19 +00:00
bin\th05\hud_bar.obj: th05\hud_bar.asm
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
bin\th05\scoreupd.obj: th04\scoreupd.asm
[Reverse-engineering] [th05] Character selection and unlock variables
2019-12-07 10:37:53 +00:00
bin\th05\op.exe: bin\th05\op.obj th05\op_01.cpp
[Maintenance] [th04/th05] Define a OP/MAIN/MAINE macro Seems to be the best way to handle all those implementation differences in the GENSOU.SCR functions. Part of P0063, funded by -Tom-.
2019-12-27 20:02:26 +00:00
$(CC) $(CFLAGS) -ml -DGAME=5 -DBINARY='O' -nbin\th05\ -eOP.EXE @&&|
[Reverse-engineering] [th05] Character selection and unlock variables
2019-12-07 10:37:53 +00:00
$**
|
[Decompilation] [th05] Character-independent shot type functions Part of P0062, funded by Touhou Patch Center.
2019-12-21 16:23:03 +00:00
bin\th05\main.exe: bin\th05\main.obj th05\p_common.cpp th05\p_reimu.cpp th05\p_marisa.cpp th05\p_mima.cpp th05\p_yuuka.cpp bin\th05\player.obj bin\th05\hud_bar.obj bin\th05\scoreupd.obj th05\main012.cpp
[Maintenance] [th04/th05] Define a OP/MAIN/MAINE macro Seems to be the best way to handle all those implementation differences in the GENSOU.SCR functions. Part of P0063, funded by -Tom-.
2019-12-27 20:02:26 +00:00
$(CC) $(CFLAGS) -ml -3 -Z -DGAME=5 -DBINARY='M' -nbin\th05\ -eMAIN.EXE @&&|
[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
$**
|
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
# ZUN.COM packing
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
bin\zuncom\zungen.com: zuncom\zungen.c
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
mkdir bin\zuncom
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
$(CC) $(CFLAGS) -mt -lt -nbin\zuncom\ -eZUNGEN.COM $**
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
bin\zuncom\zun_stub.bin: zuncom\zun_stub.asm
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
mkdir bin\zuncom
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
tasm zuncom\zun_stub.asm,bin\zuncom\zun_stub
tlink -t bin\zuncom\zun_stub.obj,bin\zuncom\zun_stub.bin
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
[th04/th05] Rebuild ZUN.COM
2018-04-15 14:37:06 +00:00
bin\zuncom\comcstm.com: zuncom\comcstm.c
mkdir bin\zuncom
$(CC) $(CFLAGS) -mt -lt -nbin\zuncom\ -eCOMCSTM.com $**
bin\zuncom\cstmstub.bin: zuncom\cstmstub.asm
mkdir bin\zuncom
tasm zuncom\cstmstub.asm,bin\zuncom\cstmstub
tlink -t bin\zuncom\cstmstub.obj,bin\zuncom\cstmstub.bin
[zuncom] Get rid of moveup.asm one less invokation of tasm+tlink == one less headache
2018-04-15 17:22:41 +00:00
ZUNCOM_PREREQ = bin\zuncom\zungen.com bin\zuncom\zun_stub.bin
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
bin\th02\zun.com : $(ZUNCOM_PREREQ) libs\kaja\ongchk.com bin\th02\zuninit.com bin\th02\zun_res.com bin\th01\zunsoft.com
[zuncom] Get rid of moveup.asm one less invokation of tasm+tlink == one less headache
2018-04-15 17:22:41 +00:00
bin\zuncom\zungen bin\zuncom\zun_stub.bin &&|
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
4
ONGCHK
ZUNINIT
ZUN_RES
ZUNSOFT
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
libs\kaja\ongchk.com
bin\th02\zuninit.com
bin\th02\zun_res.com
bin\th01\zunsoft.com
| bin\th02\zun.com
bin\th03\zun.com : $(ZUNCOM_PREREQ) libs\kaja\ongchk.com bin\th02\zuninit.com bin\th01\zunsoft.com bin\th03\zunsp.com bin\th03\res_yume.com
[zuncom] Get rid of moveup.asm one less invokation of tasm+tlink == one less headache
2018-04-15 17:22:41 +00:00
bin\zuncom\zungen bin\zuncom\zun_stub.bin &&|
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
5
-1
-2
-3
-4
-5
[th02/th03] Rebuild ZUN.COM Two DOS utilities were made for this: - gensize: generates TASM macro definitions with filesizes. - copycat: similar to copy/b a+b+c d, except a+b+c is specified in a separate file to avoid command line length limitations. th02/zun.com is bit-perfect th03/zun.com is almost there, with insignificant differences in zunsp.com and res_yume.com.
2018-04-14 17:08:22 +00:00
libs\kaja\ongchk.com
bin\th02\zuninit.com
bin\th01\zunsoft.com
bin\th03\zunsp.com
bin\th03\res_yume.com
| bin\th03\zun.com
[th04/th05] Rebuild ZUN.COM
2018-04-15 14:37:06 +00:00
bin\th04\zuncom.bin : $(ZUNCOM_PREREQ) libs\kaja\ongchk.com bin\th04\zuninit.com bin\th04\res_huma.com bin\th04\memchk.com
[zuncom] Get rid of moveup.asm one less invokation of tasm+tlink == one less headache
2018-04-15 17:22:41 +00:00
bin\zuncom\zungen bin\zuncom\zun_stub.bin &&|
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
4
-O
-I
-S
-M
[th04/th05] Rebuild ZUN.COM
2018-04-15 14:37:06 +00:00
libs\kaja\ongchk.com
bin\th04\zuninit.com
bin\th04\res_huma.com
bin\th04\memchk.com
| bin\th04\zuncom.bin
bin\th05\zuncom.bin : $(ZUNCOM_PREREQ) libs\kaja\ongchk.com bin\th05\zuninit.com bin\th05\res_kso.com bin\th05\gjinit.com bin\th05\memchk.com
[zuncom] Get rid of moveup.asm one less invokation of tasm+tlink == one less headache
2018-04-15 17:22:41 +00:00
bin\zuncom\zungen bin\zuncom\zun_stub.bin &&|
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
5
-O
-I
-S
-G
-M
[th04/th05] Rebuild ZUN.COM
2018-04-15 14:37:06 +00:00
libs\kaja\ongchk.com
bin\th05\zuninit.com
bin\th05\res_kso.com
bin\th05\gjinit.com
bin\th05\memchk.com
| bin\th05\zuncom.bin
bin\th04\zun.com : bin\zuncom\comcstm.com zuncom\zun4.txt bin\th04\zuncom.bin bin\zuncom\cstmstub.bin
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
bin\zuncom\comcstm zuncom\zun4.txt bin\th04\zuncom.bin bin\zuncom\cstmstub.bin 621381155 bin\th04\zun.com
[th04/th05] Rebuild ZUN.COM
2018-04-15 14:37:06 +00:00
bin\th05\zun.com : bin\zuncom\comcstm.com zuncom\zun5.txt bin\th05\zuncom.bin bin\zuncom\cstmstub.bin
[zuncom] Simplified build of zun.com Now it uses a single utility (zungen) to generate the header and concatenate all the files
2018-04-15 17:07:40 +00:00
bin\zuncom\comcstm zuncom\zun5.txt bin\th05\zuncom.bin bin\zuncom\cstmstub.bin 628731748 bin\th05\zun.com