Skip to content

Conversation

Phidias618
Copy link

I specified what the content of the VRAM DMA registers are once a transfer is done.

"The source and destination address regisers are both incremented by $10 bytes for each block of $10 bytes transfered after the transfer is done.
FF55 is always equal to $FF once the transfer ends."

It is useful information when multiple VRAM DMA transfer need to be performed in a row.
For example if one wants to fill VRAM with only 0 using one array of 16 null bytes as the source, as the destination address registers don't need to be updated after each transfer, but the source address registers always need to be reset back to the address of the begining of the source array after each transfer
Here is some assembly code that takes advantage of this in order to clear one bank of VRAM
_zero_x16 is an array of 16 null bytes, aligned on a 16 bytes boundary
clear_vram.s

@alloncm
Copy link
Contributor

alloncm commented Sep 17, 2025

Hi, the state of this register after a transfer complete is already described here and here (for each transfer mode).

I'm not sure if I prefer to have this info in a different section than the one describing the register behavior itself (like this PR suggesting) but I do believe we should have this info described in a single place (DRY 😄).

What do you think?

Copy link
Member

@avivace avivace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, this information is already present (and twice) - we should have it only in 1 place and maybe link/quote that paragraph if helpful

@Phidias618
Copy link
Author

These section only mentions the state of FF55 but not the state of FF51, FF52, FF53 and FF54, (these 4 register cannot be read from but knowing their state after a transfer is still useful for some purposes). That's why i added the section "State of the registers after a transfer", and i choose to include as a repeat the state of FF55 in this section in order for the section to be complete, even if that resulted in some duplicate information.
If you don't like having too much duplicate information here are some solution i have around this :

  • I can just remove the part about FF55 in the new section
  • I can move the state of the register after a transfer to the sections describing FF51-FF52 and FF53-FF54

@alloncm
Copy link
Contributor

alloncm commented Sep 26, 2025

Personally I think this is the better option:

I can move the state of the register after a transfer to the sections describing FF51-FF52 and FF53-FF54

I completely missed the description of the FF51-FF54 registers and I think moving it to the section describing how the registers behaves will help people find it easily (the state of the register after transfer is done is tightly coupled to its behavior).

Copy link
Contributor

@alloncm alloncm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While reviewing this, another question came to mind - what happens if only one register is written to after a transfer, does it updates only the relevant bits (high or low part) or it reloads both registers from the last values written.

My intuition says only the relevant bits but maybe is worth checking?

@Phidias618
Copy link
Author

Phidias618 commented Sep 27, 2025

Why would writing to one of the register revert the state of the other register of the register pair? As i understand it, the CGB VRAM DMA is just a very fast loop, as such it needs to keep track where to copy the current byte from and where to copy the current byte to, and for convenience the CGB internally uses the source and destination registers directly for that purposes without copying the them to another location, as a consequence, both the source and destination registers are incremented by $10 for each successful transfer, but most of that is unknown to the developer as these registers are write only.
I still tested what the clear VRAM function does when only the high byte of the source address is set at each iteration of the loop, and it starts copying garbage data to VRAM, probably because the source address is increasing past the end of the zero_x16 array

@Phidias618 Phidias618 requested a review from avivace October 2, 2025 19:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants