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

74 lines
1.3 KiB
NASM
Raw Normal View History

[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
.186 ; The 8086 couldn't into PUSH imm8?!
locals
include libs/master.lib/master.inc
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
include th03/arg_bx.inc
[Maintenance] Move all features exclusive to MAIN.EXE to a main/ subdirectory Adding op/, main/, and end/ directories does nicely cover a great majority of the "not really further classifiable slices" implied in d56bd45. Part of P0086, funded by [Anonymous] and Blue Bolt.
2020-04-05 14:17:33 +00:00
include th02/main/hud/hud.inc
[Maintenance] [th04] Move gaiji.inc to its own subdirectory The other games also have their own directory. Part of P0063, funded by -Tom-.
2019-12-25 14:36:11 +00:00
include th04/gaiji/gaiji.inc
[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
[Maintenance] [th02/th04/th05] Rename `HUD_TRAM_W` to `HUD_KANJI_W` Right, *_TRAM_W refers to 8-pixel halfwidth characters, and *_KANJI_W to 16-pixel full-width characters… which also include gaiji, which are what the entire HUD is made out of. Part of P0112, funded by [Anonymous] and Blue Bolt.
2020-08-27 20:26:02 +00:00
extrn _hud_gaiji_row:byte:HUD_KANJI_W
[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
; ----------------------------------------------------------------------------
[Maintenance] [th04/th05] Assemble 16-bit .ASM files case-sensitively Otherwise, TASM would simply convert all EXTRN declarations in those files to uppercase. Then, the linker would expect them in uppercase, forcing both the case-sensitive big 32-bit .ASM files *and* the entire C land to declare them as uppercase as well. For functions with __pascal convention which are always uppercased anyway, this makes no difference. It does matter for regular __cdecl variables, though, and the C declaration of [score_delta] in e6294c2 already showed that we'd then be forced to use macros if we wanted to pretend that these names still had lowercase characters. Doing this for every variable referenced in both C land and 16-bit ASM land gets annoying quickly. So, no need to force this inconsistency if we can get rid of it by slightly uglifying ASM land. Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-28 16:10:07 +00:00
MAIN_01_TEXT segment word public 'CODE' use16
assume cs:MAIN_01_TEXT
[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
; void pascal near hud_bar_put(
[Maintenance] Introduce a type for PC-98 text RAM attributes No need for signed variants this time! Part of P0262, funded by [Anonymous] and Blue Bolt.
2023-11-27 09:32:04 +00:00
; utram_y_t y, unsigned char value, tram_atrb2 atrb
[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
; );
public HUD_BAR_PUT
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
HUD_BAR_PUT proc near
arg_bx near, @atrb:word, @value:byte, @y:word
[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
push di
push ds
pop es
mov di, offset _hud_gaiji_row
[Maintenance] Rename all old *_X and *_Y constants to *_LEFT and *_TOP Part of P0112, funded by [Anonymous] and Blue Bolt.
2020-08-25 18:29:24 +00:00
push HUD_LEFT
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
push @y
[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
push ds
push di
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
push @atrb
[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
mov al, g_BAR_MAX
[Maintenance] [th02/th04/th05] Rename `HUD_TRAM_W` to `HUD_KANJI_W` Right, *_TRAM_W refers to 8-pixel halfwidth characters, and *_KANJI_W to 16-pixel full-width characters… which also include gaiji, which are what the entire HUD is made out of. Part of P0112, funded by [Anonymous] and Blue Bolt.
2020-08-27 20:26:02 +00:00
mov cx, HUD_KANJI_W
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
mov bl, @value
[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
cmp bl, BAR_MAX
jb short @@below_max
@@at_max:
stosb
inc al
loop @@at_max
jmp short @@put
; ---------------------------------------------------------------------------
@@below_max:
mov dl, bl
dec al
jmp short @@cell_still_fully_filled?
; ---------------------------------------------------------------------------
@@cell_is_fully_filled:
stosb
@@cell_still_fully_filled?:
dec cx
sub dl, BAR_GAIJI_MAX
jg short @@cell_is_fully_filled
mov al, bl
dec al
and al, BAR_GAIJI_MAX - 1
add al, G_BAR
stosb
mov al, g_EMPTY
rep stosb
@@put:
[Maintenance] [th04/th05] Assemble 16-bit .ASM files case-sensitively Otherwise, TASM would simply convert all EXTRN declarations in those files to uppercase. Then, the linker would expect them in uppercase, forcing both the case-sensitive big 32-bit .ASM files *and* the entire C land to declare them as uppercase as well. For functions with __pascal convention which are always uppercased anyway, this makes no difference. It does matter for regular __cdecl variables, though, and the C declaration of [score_delta] in e6294c2 already showed that we'd then be forced to use macros if we wanted to pretend that these names still had lowercase characters. Doing this for every variable referenced in both C land and 16-bit ASM land gets annoying quickly. So, no need to force this inconsistency if we can get rid of it by slightly uglifying ASM land. Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-28 16:10:07 +00:00
call GAIJI_PUTSA
[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
pop di
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
ret_bx
HUD_BAR_PUT endp
[Maintenance] [th04/th05] Assemble 16-bit .ASM files case-sensitively Otherwise, TASM would simply convert all EXTRN declarations in those files to uppercase. Then, the linker would expect them in uppercase, forcing both the case-sensitive big 32-bit .ASM files *and* the entire C land to declare them as uppercase as well. For functions with __pascal convention which are always uppercased anyway, this makes no difference. It does matter for regular __cdecl variables, though, and the C declaration of [score_delta] in e6294c2 already showed that we'd then be forced to use macros if we wanted to pretend that these names still had lowercase characters. Doing this for every variable referenced in both C land and 16-bit ASM land gets annoying quickly. So, no need to force this inconsistency if we can get rid of it by slightly uglifying ASM land. Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-28 16:10:07 +00:00
MAIN_01_TEXT ends
[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
end