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

284 lines
5.3 KiB
C
Raw Normal View History

[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
// ReC98
// -----
// PC-98 hardware constants not covered by master.lib
[Maintenance] Declare distinct types for pixel and VRAM sizes Oh wait, we also need one of those for an upcoming structure! Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-21 18:13:08 +00:00
/// Spaces
/// ------
/// These don't necessarily have to be relative to the top-left corner of the
/// display.
// Display-space widths, heights, and object-space coordinates
typedef int pixel_t;
typedef unsigned int upixel_t;
// VRAM widths and object-space coordinates
typedef int vram_byte_amount_t;
typedef int vram_word_amount_t;
typedef int vram_dword_amount_t;
/// ------
[Maintenance] Declare distinct types for screen, VRAM, and TRAM coordinates Whew, time to look at every `int` variable we ever declared! The best moment to do this would have been a year ago, but well, better late than never. No need to communicate that in comments anymore. These shouldn't be used for widths, heights, or sprite-space coordinates. Maybe we'll cover that another time, this commit is already large enough. Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-20 19:59:45 +00:00
/// Coordinate systems
/// ------------------
/// All of these are relative to the top-left corner of the final display.
/// MODDERS: Remove the unsigned varieties.
// Display-space coordinate, with [0; RES_X[ being the visible area.
typedef int screen_x_t;
typedef unsigned int uscreen_x_t;
// Display-space coordinate, with [0; RES_Y[ being the visible area. Does not
// care about 200- or 400-line graphics modes or vertical scrolling.
typedef int screen_y_t;
typedef unsigned int uscreen_y_t;
// VRAM X coordinate, ranging from 0 to (RES_X / BYTE_DOTS).
typedef int vram_x_t;
// VRAM Y coordinate, ranging from 0 to either 400 or 200 depending on the
// current graphics mode, and with an added vertical scrolling offset.
typedef int vram_y_t;
typedef unsigned int uvram_y_t;
// Text RAM X coordinate, ranging from 0 to (RES_X / GLYPH_HALF_W).
typedef int tram_x_t;
typedef unsigned int utram_x_t;
// Text RAM Y coordinate, ranging from 0 to (RES_Y / GLYPH_H).
typedef int tram_y_t;
typedef unsigned int utram_y_t;
/// ------------------
[Reverse-engineering] [th04/th05] graph_putsa_fx
2019-11-26 11:51:08 +00:00
/// Text
/// ----
[Reverse-engineering] [th03] 1P/2P selection gaiji cursor Part of P0064, funded by Touhou Patch Center.
2019-12-28 20:20:48 +00:00
#define GAIJI_W 16
#define GAIJI_TRAM_W (GAIJI_W / 8)
[Maintenance] [th01/th02] Split graph_putsa_fx() into its shared parts I did consider not doing this, because "well, can't anyone who's *actually* interested just diff the TH01 and TH02 implementations to figure out the differences themselves", but that duplication ended up feeling too filthy after all. And hey, it's a nice excuse to update TH02's version to current naming standards! 😛 Part of P0068, funded by Yanga.
2020-01-13 21:52:19 +00:00
#define GLYPH_HALF_W 8
#define GLYPH_FULL_W 16
#define GLYPH_H 16
[Reverse-engineering] [th04/th05] graph_putsa_fx
2019-11-26 11:51:08 +00:00
/// ----
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
/// Graphics
/// --------
[Maintenance] #define the number of dots in a byte One fewer magic number. And one more deliberate dependency on a PC-98-specific hardware constant, to further drive home just how unportable these games are, even once decompilation will be complete. Part of P0105, funded by Yanga.
2020-08-05 21:04:47 +00:00
#define BYTE_DOTS 8
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
#define RES_X 640
#define RES_Y 400
[Maintenance] #define the number of dots in a byte One fewer magic number. And one more deliberate dependency on a PC-98-specific hardware constant, to further drive home just how unportable these games are, even once decompilation will be complete. Part of P0105, funded by Yanga.
2020-08-05 21:04:47 +00:00
#define ROW_SIZE (RES_X / BYTE_DOTS)
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
#define PLANE_SIZE (ROW_SIZE * RES_Y)
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
[Reverse-engineering] [th01] Current back page Previously sloppily mis-RE'd as "some page variable, idk", back in 2015… Now also with a page number typedef. And yeah, restricting bool to C++ has now proven to be stupid after all. Part of P0067, funded by Splashman.
2020-01-06 13:40:42 +00:00
typedef bool page_t;
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
#define COLOR_COUNT 16
[Decompilation] [th01] Whole-page color fills and copies Page… 2? On a system with only page 0 and 1? Had to get out my real PC-98 to double-check that I wasn't missing anything here, since every emulator only looks at the bottom bit of the page number. But real hardware seems to do the same, and there really is nothing special to it semantically, being equivalent to page 0. 🤷 Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 16:15:24 +00:00
// The 16-color mode supports 4 bits per RGB component, for a total of
// 4,096 colors
typedef int8_t uint4_t;
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
#ifdef __cplusplus
[Decompilation] Encode the per-component range in the RGB color template Allowing us to then retrieve it using a function call with no run-time cost, although we do have to be careful with the types here. Also, is that another solution to decompilation puzzles that involve types of number literals? Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 11:24:18 +00:00
template <class ComponentType, int Range> union RGB {
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
struct {
ComponentType r, g, b;
} c;
ComponentType v[3];
[Decompilation] Encode the per-component range in the RGB color template Allowing us to then retrieve it using a function call with no run-time cost, although we do have to be careful with the types here. Also, is that another solution to decompilation puzzles that involve types of number literals? Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 11:24:18 +00:00
// Yes, we actually need this function in certain cases where code
// generation calls for a 0 in the ComponentType.
static ComponentType min() {
return 0;
}
static ComponentType max() {
return (Range - 1);
}
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
};
template <class RGBType> struct Palette {
RGBType colors[COLOR_COUNT];
[Decompilation] Overload operator[] for palettes Which has no run-time cost in almost all cases. Part of P0080, funded by Ember2528 and Splashman.
2020-03-03 10:45:03 +00:00
[Decompilation] Encode the per-component range in the RGB color template Allowing us to then retrieve it using a function call with no run-time cost, although we do have to be careful with the types here. Also, is that another solution to decompilation puzzles that involve types of number literals? Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 11:24:18 +00:00
static int range() {
return RGBType::Range;
}
[Decompilation] Overload operator[] for palettes Which has no run-time cost in almost all cases. Part of P0080, funded by Ember2528 and Splashman.
2020-03-03 10:45:03 +00:00
RGBType& operator [](int col) {
return colors[col];
}
[Decompilation] [th01] Basic hardware palette and GRCG functions No macros for the port numbers here! Anyone who will try to read and understand this code will probably want to look those up in PC-98 hardware documentation, and macros would just be an annoying layer of indirection then. Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 17:48:44 +00:00
const RGBType& operator [](int col) const {
return colors[col];
}
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
};
[Decompilation] Encode the per-component range in the RGB color template Allowing us to then retrieve it using a function call with no run-time cost, although we do have to be careful with the types here. Also, is that another solution to decompilation puzzles that involve types of number literals? Part of P0080, funded by Ember2528 and Splashman.
2020-03-01 11:24:18 +00:00
typedef RGB<uint4_t, 16> RGB4;
[Maintenance] Templatize RGB and palette types for 4- and 8-bit components Right, PC-98 hardware only supports 4 bits per RGB component, for a total of 4,096 possible colors. The 8-bit RGB color values we've been seeing throughout the later games are a master.lib extension, to allow for more toning precision. Which TH01, with all its NIH syndrome, doesn't use. And yup, that means templates in the most basic header files… Since that would have meant renaming *everything* to compile as C++, I simply made these types exclusive to C++ code, thcrap style. Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 11:05:42 +00:00
typedef Palette<RGB4> Palette4;
#endif
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
/// --------
[Decompilation] [th01] Inter-page rectangle moves Semi-unused, that is, the one use of this function doesn't actually move the rectangle to a different position. Ironically, the non-moving back-to-front function immediately above *is* unused… Also, too bad that stack order is the only reason we can't use structs to combine all plane variables into a single object. Part of P0067, funded by Splashman.
2020-01-10 20:25:29 +00:00
/// Memory segments
/// ---------------
#define SEG_PLANE_B 0xA800
#define SEG_PLANE_R 0xB000
#define SEG_PLANE_G 0xB800
#define SEG_PLANE_E 0xE000
[Reverse-engineering] [th03] CDG: VRAM plane iteration Which is where ZUN adds those additional 0x2000 to make the jump from the 0xB800 plane to the 0xE000 plane. Part of P0114, funded by Lmocinemod.
2020-09-06 22:21:38 +00:00
// Segment distance between B↔R↔G
#define SEG_PLANE_DIST_BRG 0x800
// Segment distance between G↔E
#define SEG_PLANE_DIST_E 0x2800
[Decompilation] [th01] Inter-page rectangle moves Semi-unused, that is, the one use of this function doesn't actually move the rectangle to a different position. Ironically, the non-moving back-to-front function immediately above *is* unused… Also, too bad that stack order is the only reason we can't use structs to combine all plane variables into a single object. Part of P0067, funded by Splashman.
2020-01-10 20:25:29 +00:00
/// ---------------
[Maintenance] Move PC-98 hardware constants to a separate include file SPRITE16 would also like to refer to those later. Part of P0061, funded by Touhou Patch Center.
2019-11-08 20:03:03 +00:00
/// Keyboard
/// --------
typedef enum {
K0_ESC = 0x01,
K0_1 = 0x02,
K0_2 = 0x04,
K0_3 = 0x08,
K0_4 = 0x10,
K0_5 = 0x20,
K0_6 = 0x40,
K0_7 = 0x80
} keygroup_0;
typedef enum {
K1_8 = 0x01,
K1_9 = 0x02,
K1_0 = 0x04,
K1_MINUS = 0x08,
K1_CIRCUMFLEX = 0x10,
K1_YEN = 0x20,
K1_BACKSPACE = 0x40,
K1_TAB = 0x80
} keygroup_1;
typedef enum {
K2_Q = 0x01,
K2_W = 0x02,
K2_E = 0x04,
K2_R = 0x08,
K2_T = 0x10,
K2_Y = 0x20,
K2_U = 0x40,
K2_I = 0x80
} keygroup_2;
typedef enum {
K3_O = 0x01,
K3_P = 0x02,
K3_AT = 0x04,
K3_LBRACKET = 0x08,
K3_RETURN = 0x10,
K3_A = 0x20,
K3_S = 0x40,
K3_D = 0x80
} keygroup_3;
typedef enum {
K4_F = 0x01,
K4_G = 0x02,
K4_H = 0x04,
K4_J = 0x08,
K4_K = 0x10,
K4_L = 0x20,
K4_PLUS = 0x40,
K4_ASTERISK = 0x80
} keygroup_4;
typedef enum {
K5_RBRACKET = 0x01,
K5_Z = 0x02,
K5_X = 0x04,
K5_C = 0x08,
K5_V = 0x10,
K5_B = 0x20,
K5_N = 0x40,
K5_M = 0x80
} keygroup_5;
typedef enum {
K6_COMMA = 0x01,
K6_PERIOD = 0x02,
K6_SLASH = 0x04,
K6_UNDERSCORE = 0x08,
K6_SPACE = 0x10,
K6_XFER = 0x20,
K6_ROLL_UP = 0x40,
K6_ROLL_DOWN = 0x80
} keygroup_6;
typedef enum {
K7_INS = 0x01,
K7_DEL = 0x02,
K7_ARROW_UP = 0x04,
K7_ARROW_LEFT = 0x08,
K7_ARROW_RIGHT = 0x10,
K7_ARROW_DOWN = 0x20,
K7_HOME_CLR = 0x40,
K7_END = 0x80
} keygroup_7;
typedef enum {
K8_NUM_MINUS = 0x01,
K8_NUM_DIV = 0x02,
K8_NUM_7 = 0x04,
K8_NUM_8 = 0x08,
K8_NUM_9 = 0x10,
K8_NUM_MUL = 0x20,
K8_NUM_4 = 0x40,
K8_NUM_5 = 0x80
} keygroup_8;
typedef enum {
K9_NUM_6 = 0x01,
K9_NUM_PLUS = 0x02,
K9_NUM_1 = 0x04,
K9_NUM_2 = 0x08,
K9_NUM_3 = 0x10,
K9_NUM_EQUALS = 0x20,
K9_NUM_0 = 0x40,
K9_NUM_COMMA = 0x80
} keygroup_9;
typedef enum {
K10_NUM_PERIOD = 0x01,
K10_NFER = 0x02,
K10_VF1 = 0x04,
K10_VF2 = 0x08,
K10_VF3 = 0x10,
K10_VF4 = 0x20,
K10_VF5 = 0x40
} keygroup_10;
typedef enum {
K11_NUM = 0x02,
// Couldn't find any info whatsoever on the next three, but they're
// listed in MEMSYS.TXT, so...
K11_SYMBOL_SHIFT = 0x04,
K11_VOWEL_SHIFT = 0x08,
K11_CONSONANT_SHIFT = 0x10,
K11_HOME = 0x40
} keygroup_11;
typedef enum {
K12_STOP = 0x01,
K12_COPY = 0x02,
K12_F1 = 0x04,
K12_F2 = 0x08,
K12_F3 = 0x10,
K12_F4 = 0x20,
K12_F5 = 0x40,
K12_F6 = 0x80
} keygroup_12;
typedef enum {
K13_F7 = 0x01,
K13_F8 = 0x02,
K13_F9 = 0x04,
K13_F10 = 0x08
} keygroup_13;
typedef enum {
K14_SHIFT = 0x01,
K14_CAPS = 0x02,
K14_KANA = 0x04,
K14_GRPH = 0x08,
K14_CTRL = 0x10
} keygroup_14;
/// --------