[go: up one dir, main page]

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

Inconsistent formatting of register section titles #163

Open
3 tasks
ISSOtm opened this issue Feb 19, 2021 · 10 comments
Open
3 tasks

Inconsistent formatting of register section titles #163

ISSOtm opened this issue Feb 19, 2021 · 10 comments
Labels
awaiting feedback consistency - style Content format, text style, consistency in presenting the informations content Improvements or additions to documentation good first issue Good for newcomers
Milestone

Comments

@ISSOtm
Copy link
Member
ISSOtm commented Feb 19, 2021
  • Settle on an overall format
  • Decide how to format "R/W"
  • Decide on how to format compat info

Original OP below.


#124 changed the register anchor format from ADDR - NAME - Descr (R/W) to ADDR - NAME (Descr) (R/W), but the old style is still present elsewhere (e.g. IF still uses it).

Which format do we want to settle on (not necessarily either of these)?

@ISSOtm ISSOtm added content Improvements or additions to documentation good first issue Good for newcomers consistency - style Content format, text style, consistency in presenting the informations awaiting feedback labels Feb 19, 2021
@avivace avivace added this to the v0.1.0 milestone Mar 10, 2021
@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 14, 2021

What's the status on this? There's been a lot of cleanup recently, we should survey the document on whether this has been fixed.

@avivace avivace added this to Triage in Development Board Jul 24, 2021
@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 26, 2021

Section titles can be checked using some ungodly regexes, so I'll see to this this evening.

sed -E 's,^.*<h[1-6]\s+id="[^"]+"><a(\s+[^=>]+="[^"]*")*>([^<]*)</a>.*$,\2,;t;d' docs/pandocs/print.html

@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 27, 2021

Another inconsistency we have is (R) vs. (Read Only), and (R/W) vs. (Read/Write).

I suggest (Read-only) and (Read/Write) respectively, for clarity.

@aaaaaa123456789
Copy link
Member

FF40 - LCDC - LCD control (read/write) seems good enough to me. No capitalization in the parentheses, as they are not beginning a new sentence.

@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 27, 2021

Since we're changing all reg descriptions, I'll say that I'm fond of neither current style (ADDR - Name - CGB only - Description (R/W), ADDR - Name (Description) (R/W) - CGB only). I'd prefer e.g. ADDR - Name: Description (R/W) [CGB only], since it's imo more structured.

Additionally, we need to set a rule for when a register is partially readable and partially writable (or both). The current style seems to be not to mention the property at all, and I agree with it.

@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 27, 2021

Another note: make sure to correctly differentiate "CGB only" (= the register is writable even in compat mode) and "CGB Mode only"; this should also be defined somewhere. (At this point, I think that #194 wouldn't be enough, and we would additionally need a "Conventions" page...)

@aaaaaa123456789
Copy link
Member

If a register has unused bits, but all the usable bits have the same accessibility (e.g., SVBK), it should be labelled by the usable bits. If usable bits differ in accessibility (e.g., P1/JOYP), not mentioning it at all should be okay, since the list of bits will need accessibility indicators anyway.

As for CGB registers, that could be marked in the same parenthetical to avoid bracket overload: (read/write, CGB mode only).

@daid
Copy link
Contributor
daid commented Jul 27, 2021

Checked a few datasheets, most do not mention R/W in the register title at all, and only per bit.

Examples:
image
image

@aaaaaa123456789
Copy link
Member

That's reasonable when registers are mostly bitfields, but the GB has many that aren't. For instance, there's no reason to specify a per-bit accessibility of SCX.
And if you have to specify byte-wide accessibility in some cases, why not do it whenever it is reasonable?

@ISSOtm
Copy link
Member Author
ISSOtm commented Jul 27, 2021

Given that we don't specify bits individually, but whole bitfields at once, this would be less of a burden.

@ISSOtm ISSOtm moved this from Triage to In progress in Development Board Jul 30, 2021
@ISSOtm ISSOtm moved this from In progress to To do in Development Board Aug 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback consistency - style Content format, text style, consistency in presenting the informations content Improvements or additions to documentation good first issue Good for newcomers
Projects
Development

No branches or pull requests

4 participants