2018-12-21 22:03:25 +00:00
|
|
|
; Fills the given playfield rows between ES:0 (top row) and ES:DI (left byte
|
|
|
|
|
; in the bottom row) with the current GRCG tile.
|
|
|
|
|
; Assumes that the GRCG is set to TDW mode.
|
|
|
|
|
|
|
|
|
|
; void __usercall grcg_fill_playfield_rows(void far *vram_byte_at_bottom_left<es:di>);
|
|
|
|
|
public _grcg_fill_playfield_rows
|
|
|
|
|
_grcg_fill_playfield_rows proc near
|
|
|
|
|
mov cx, PLAYFIELD_VRAM_W / 4
|
|
|
|
|
rep stosd
|
|
|
|
|
sub di, ROW_SIZE + PLAYFIELD_VRAM_W
|
|
|
|
|
jge short _grcg_fill_playfield_rows
|
|
|
|
|
retn
|
|
|
|
|
_grcg_fill_playfield_rows endp
|
[Maintenance] [th04] Split code segment #1 into two
So yes, we *can* technically decompile from anywhere, by splitting the
segment after the function we want, then .SEQuentially GROUPing the two
segments back together into one virtual segment matching the original
one. This gives us one more point where we can slot in new compilation
units that emit their code into the same segment, in the order given on
the link command line.
*But* since all ASM in ReC98 heavily relies on being assembled in MASM
mode, we then start to suffer from MASM's group addressing quirk,
described in the "Accessing data in a segment belonging to a group"
section in the Turbo Assembler Version 5 User's Guide.
Which then forces us to manually prefix every single function call
• from inside the group
• to anywhere else within the newly created segment
with the group name. It's stupidly boring busywork, because of all the
function calls you *mustn't* prefix. Special tooling might make this
easier, but I don't have it, and I'm not getting crowdfunded for it.
And while this is faster than porting the entire codebase to Ideal
mode, I'll only do this on rare occasions.
Like the upcoming, particularly awful piece of reverse-engineering.
Completes P0031, funded by zorg.
2019-09-17 20:47:44 +00:00
|
|
|
nop
|