Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th04/math/randring.inc

34 lines
765 B
PHP
Raw Normal View History

[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
RANDRING_NEXT_DEF macro instance
[Maintenance] Export all pascal functions with their proper uppercase names Yup, that was one massive screw-up. Part of P0030, funded by zorg.
2019-09-15 16:23:33 +00:00
public RANDRING&instance&_NEXT16
randring&instance&_next16 proc near
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
mov bx, _randring_p
mov ax, word ptr _randring[bx]
inc byte ptr _randring_p
ret
[Maintenance] Export all pascal functions with their proper uppercase names Yup, that was one massive screw-up. Part of P0030, funded by zorg.
2019-09-15 16:23:33 +00:00
randring&instance&_next16 endp
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
nop
[Maintenance] Export all pascal functions with their proper uppercase names Yup, that was one massive screw-up. Part of P0030, funded by zorg.
2019-09-15 16:23:33 +00:00
public RANDRING&instance&_NEXT16_AND
[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
randring&instance&_next16_and proc near
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
mov bx, _randring_p
mov ax, word ptr _randring[bx]
inc byte ptr _randring_p
[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
arg_bx near, @mask:byte
and ax, @mask
ret_bx
randring&instance&_next16_and endp
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
nop
[Maintenance] Export all pascal functions with their proper uppercase names Yup, that was one massive screw-up. Part of P0030, funded by zorg.
2019-09-15 16:23:33 +00:00
public RANDRING&instance&_NEXT16_MOD
[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
randring&instance&_next16_mod proc near
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
mov bx, _randring_p
mov ax, word ptr _randring[bx]
inc byte ptr _randring_p
xor dx, dx
[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
arg_bx near, @n:word
div word ptr @mask
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
mov ax, dx
[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
randring&instance&_next16_mod endp
[Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer Yes, you're reading that correctly. If the cursor is at 255, reading a 16-bit value will fill the upper 8 bits with the neighboring cursor value, which always is 0xFF. Funded by -Tom-.
2018-03-16 08:19:50 +00:00
endm