Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rHDMAx alternative names #36

Open
zlago opened this issue Nov 11, 2022 · 12 comments
Open

rHDMAx alternative names #36

zlago opened this issue Nov 11, 2022 · 12 comments

Comments

@zlago
Copy link
Contributor

zlago commented Nov 11, 2022

some registers have alternative, more "user friendly" names (rKEY1, rNRxx, CGB palette registers, CGB banking registers)
but since rHDMAx registers dont have alternative names and (according to hardware.inc and pandocs) are big-endian, this could result in some nasty suprises if someone doesnt double check the order
my suggested alternative names for rHDMAx registers would be: rHDMA_SRC_HI, rHDMA_SRC_LO, rHDMA_DST_HI, rHDMA_DST_LO, and rHDMA_LEN

@zlago
Copy link
Contributor Author

zlago commented Nov 13, 2022

after looking into it a bit more, here are more suggestions/questions i have:

  • the CGB banking register are.. not exactly intuitive, how about adding rSWBK/rWBK for the WRAM bank?
  • would anyone use a constant for the unreliable WX=0 and WX=166?
  • a constant for the size of a CGB palette (4 colors)
  • CGB palette constants have flag versions for their alternative names, but some other constants dont (rSPD but no SPDF_PREPARE or SPDF_DBLSPEED)
  • why is it KEY1F_DBLSPEED and not just KEY1F_SPEED?
  • a constant for $e4? something like BGP_DEFAULT?

@ISSOtm
Copy link
Member

ISSOtm commented Nov 13, 2022

Do we have any registers with an underscore in their name? (On that point, this might overlap #26.)

If we are renaming those registers, I'd go the extra mile and call them rVBANK and rWBANK, for example.

hardware.inc aims to provide constants that would be used often, so providing some for fringe cases is imo not worth it. Mentioning the values in the doc comment if they aren't already would be good.

At that point, why not one for the number of palettes, or the byte size of a colour? Why that specifically?

Arguably, KEY1 bit 7 can be treated as a boolean indicating whether double-speed mode is active, so the name seems logical.

That constant is nothing particular, and if we start being opinionated, @aaaaaa123456789 won't let me hear the end of it.

@zlago
Copy link
Contributor Author

zlago commented Nov 13, 2022

  • uhh poor wording on my part i assume
  • okay rVBANK and rWBANK makes much more sense than more arbitrary names
  • just wanted to ask if a constant for an edge case could belong in hardware.inc
  • i was thinking of CGB palette constants in general
  • okay
  • rBGP = $e4 is used for SGB VRAM transfers, and we could also define an LCDC constant for that

@ISSOtm
Copy link
Member

ISSOtm commented Nov 13, 2022

  • i was thinking of CGB palette constants in general

That is what I was replying to.

  • rBGP = $e4 is used for SGB VRAM transfers, and we could also define an LCDC constant for that

Okay, maybe a BGP_IDENTITY constant could make sense, then?

@aaaaaa123456789
Copy link
Member

That makes little sense, because (1) it's the identity for all palettes, not just BGP and (2) it's just a random constant. Unless the goal of hardware.inc is to pollute people's namespaces as much as possible...

Please remember this is not a "library of good stuff"; it's a file meant for hardware constants. You could argue that the default palette mapping is a hardware constant, but that's the worst slippery slope ever: how long until every register gets its constant?

@ISSOtm
Copy link
Member

ISSOtm commented Nov 13, 2022

I didn't want to include it as "the default mapping" either, but as "the palette you will want for your SGB VRAM transfers", I think it makes sense. I don't think that rationale is a slippery slope, either?

@zlago
Copy link
Contributor Author

zlago commented Nov 13, 2022

okay so to make sure were all on the same page

  • no one has anything against the suggested rHDMAx alternative names
  • banking registers will get alternative names
  • possibly some constants for Color RAM?
  • $e4 clearly marked as a SGB VRAM transfer constant
  • seemingly no response to my (as i understand it, poorly worded) question about why only some flag/byte constants have versions for alternative names? (rBCPS/BGPI has BCPSF_AUTOINC and BGPIF_AUTOINC, while rKEY1/rSPD has KEY1F_PREPARE but not SPDF_PREPARE)

@aaaaaa123456789
Copy link
Member

I didn't want to include it as "the default mapping" either, but as "the palette you will want for your SGB VRAM transfers", I think it makes sense. I don't think that rationale is a slippery slope, either?

This is just a convenience, and at worst, a convention. If you always have your palette set to some other color permutation, you can perfectly set up the SGB data to use that permutation so that you don't have to switch palettes. (I wonder if this is more efficient.) Likewise, you can, as we discussed earlier, manipulate that value for effects — the fact that few games can take advantage of those effects doesn't make them not exist.

@aaaaaa123456789
Copy link
Member

Since I haven't commented on the register name issue: I'd rather not have hardware.inc invent register names. As I said: it is not a "library of good stuff". The alternate names that are already there have to remain there for backward compatibility, and at the same time, they were already in use by the community. But the goal should never be to sanction names that don't exist yet: it is a terrible idea for a project like this to become a source of descended-from-above invented conventions that two or three people decide in a random backroom for everyone to use.

If you want to create your own names for your own projects, there's a million better ways that don't intrude on other people's code.

@zlago
Copy link
Contributor Author

zlago commented Nov 14, 2022

Do we have any registers with an underscore in their name? (On that point, this might overlap #26.)

only now did i realise you meant my suggested rHDMAx alternatives.. as it turns out, when writting them, i was looking at flag constants and not register constants.. yikes!

and i agree with ax6, should we close the issue?

@ISSOtm
Copy link
Member

ISSOtm commented Nov 15, 2022

There is, in fact, a good reason to invent register names: what good are they if they're opaque? I can give LCDC and STAT a pass for being at least somewhat evocative of their topic, but HDMA1–5 really aren't.

Besides, we already have a precedent, in the form of the audio registers, and I remember the addition being well-received.

@zlago
Copy link
Contributor Author

zlago commented Nov 15, 2022

how about an "experimental" update? the constants get a clear "these may be removed at any point" label, and depending on user feedback they will either stay, or be deprecated/removed?

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

No branches or pull requests

3 participants