On Thu, 15 Jan 2026, Chad Jablonski wrote:
Writing to any of the HOST_DATA0-7 registers pushes the written data
into a 128-bit accumulator. When the accumulator is full a flush is
triggered to copy it to the framebuffer. A final write to HOST_DATA_LAST
will also initiate a flush. The flush itself is left for the next patch.
Unaligned HOST_DATA* writes result in, from what I can tell, undefined
behavior on real hardware. A well-behaved driver shouldn't be doing this
anyway. For that reason they are not handled here at all.
Signed-off-by: Chad Jablonski <[email protected]>
---
hw/display/ati.c | 32 ++++++++++++++++++++++++++++++++
hw/display/ati_dbg.c | 9 +++++++++
hw/display/ati_int.h | 8 ++++++++
hw/display/ati_regs.h | 9 +++++++++
4 files changed, 58 insertions(+)
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 21339d7e26..e6868ddb8b 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -568,6 +568,13 @@ static inline void ati_reg_write_offs(uint32_t *reg, int
offs,
}
}
+static void ati_host_data_reset(ATIHostDataState *hd)
+{
+ hd->next = 0;
+ hd->row = 0;
+ hd->col = 0;
+}
I wonder where the real chip keeps track of these. Isn't this where the
dst_x dst_y would be updated? Or it may have some internal state not
exposed as registers? Maybe if you can dump registers you could compare
their values during blits after each host data reg write and check how
they change to reveal if any of them are updated? (But only if you're
curious; it would do for emulation using this approach with a separate
state as well.)
Regards,
BALATON Zoltan
