Skip to content

Improve "The Timing of LYC STAT Handlers" #42

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

Merged
merged 27 commits into from
Mar 23, 2022
Merged

Improve "The Timing of LYC STAT Handlers" #42

merged 27 commits into from
Mar 23, 2022

Conversation

ISSOtm
Copy link
Member

@ISSOtm ISSOtm commented Jan 8, 2022

Largely editing work, but also some content changes.

[EDIT] The article as of 2022-02-28 is now online

@rondnelson99
Copy link
Contributor

rondnelson99 commented Jan 9, 2022

Thanks so much for these changes. They definitely add a lot of polish to the document. The only change I'm a little unsure about is the one regarding hardware.inc constants. I added the STATB_xxxx constants to hardware.inc back in august, so they are present as long as the reader is using a recent version. I personally prefer using these constants with set and res so that it is more clear that I'm setting and resetting bits. I find it especially confusing when people invert the flag constants when resetting bits with and. Most importantly, I also use those flags when reading STAT later in the tutorial using bit n, [hl]. Since and and or aren't usable this way, the STATB_xxxx constants need to be used anyways, so I was inclined to use them throughout the whole document for consistency. I get why you'd want to use the older constants that everyone is more familiar with though.

@ISSOtm
Copy link
Member Author

ISSOtm commented Jan 9, 2022

Yeah, STATB_ constants are present, but LCDCB_ aren't.

@rondnelson99
Copy link
Contributor

Right, yeah, my bad. Come to think of it, I wonder why I didn't add those when I added all those other bit numbers to hardware.inc. I probably just missed them.

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.

Wow, this looks impressive (and definitely not overkilled :P). Congrats on the custom Vue component @ISSOtm 🥳

Some stuff I'd like to do:

  • propose a new palette (and maybe make it consistent also with similar graphical assets on Pan Docs)
  • set the "Scanline cycle" numbers to monospaced (or fixed-width sans serif)
  • Replace the first timing image from Pan Docs with its SVG version, using Pan Docs upstream location so the two remain in sync
  • see if there's a workaround for an artifact I still see at some zoom levels (see the purple 1-pixel line at the bottom):
    image

A part from that it looks like an appreciated and already merge-able upgrade.

@ISSOtm
Copy link
Member Author

ISSOtm commented Jan 10, 2022

Wow, this looks impressive (and definitely not overkilled :P).

Thank you! And hey, aiming too high is how we got a lot of our resources where they are, isn't it? 😜

Congrats on the custom Vue component @ISSOtm 🥳

It took some effort form both of us, but I'm mostly glad that what I bodged up didn't make you want to throw up too hard 😅

Some stuff I'd like to do:

  • propose a new palette (and maybe make it consistent also with similar graphical assets on Pan Docs)

That I'll leave to you, both so that I can focus on improving the content, and because you're much better at this task than I. (All I could do to pick colors for the Pan Docs SVGs was use a colorblind-friendly palette as-is...)

  • set the "Scanline cycle" numbers to monospaced (or fixed-width sans serif)

Should be a simple fix indeed. Note that we currently are using what seems to be Vuepress' default font stack and not Inter.

  • Replace the first timing image from Pan Docs with its SVG version, using Pan Docs upstream location so the two remain in sync

I don't think it would be possible to pull the image directly from Pan Docs. It should however be possible to e.g. have CI warn when deploying if the upstream image was updated, which should be the next best thing.

I'll look into making it themed as well, though as you suggested this is likely to require a special plugin since <style> inside SVGs trigger a failsafe (?) in Vuepress, and it'd be nice to have the "image" partial be external anyway.

A part from that it looks like an appreciated and already merge-able upgrade.

Well, the content still needs some changes (mostly editorial, like polishing the article's pacing a bit, showcasing STAT VRAM accesses with a block of code and a more detailed explanation) as well as corrections (some timings were incorrect, and thus some timelines are no longer consistent with the text). So I don't think it should be merged as-is—hence the draft status, actually.

class: className,
condensed: slotProps.op === 'condensed',
};
let contents = props.condensed ? h('b', {}, '(...)') : instrName && h('code', {}, instrName);
Copy link
Member

Choose a reason for hiding this comment

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

image

I think a simple ... fits better, why is that in bold and between parenthesis?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because otherwise it was too easy to miss

@avivace
Copy link
Member

avivace commented Jan 29, 2022

I'm trying to work on a updated palette. Main issue now is how bright STAT read

image

and call some func are

image

Also, some of the timeline graphs reach eight different colors.. That's definitely too much and confusing but I still didn't manage to find a better solution..

@ISSOtm
Copy link
Member Author

ISSOtm commented Jan 29, 2022

Agree about the yellow, but I'm having a hard time getting good-looking colors with both the light and dark schemes.

Are that many colors a problem? They are separated into two columns, after all?

ISSOtm added 20 commits January 31, 2022 22:53
Use single quotes or code blocks where appropriate instead
8 is typically too much in <pre> blocks on the Web
Should improve readability
Should help ground the introduction
Those are not part of their names, and rather indicate addresses
They should be somewhat more readable, though there is still romm for improvement
Not just the one it starts on, but all that it goes through
This will allow the next change to pull some of the lines programmatically
This will propagate modifications made to one to the other as well.
Additionally, this uncovered a couple of slip-ups, which were corrected.
And make it follow the theme as well, of course!
Shorter and independent of the `.temp` folder location
Use a set of colorblind-friendly colors
Do not color IO instructions specially besides their important cycle
Make the specific IO cycle pop out more
Only label that specific cycle in the legend
Add "..." to imply their purpose more strongly, and make that bold
to make it stand out a bit more against the background
That's a much more accurate label
It would *remove* everything before the semicolon, which is the opposite of what we want
Makes them easier to read, since entries are introduced in the same order that
they are in the timeline being labelled
@avivace avivace marked this pull request as ready for review March 23, 2022 09:54
@avivace
Copy link
Member

avivace commented Mar 23, 2022

Thanks @ISSOtm I'll start merging it in the current state and we can proceed from here with another PR

@avivace avivace merged commit 7b0b5f8 into gbdev:dev Mar 23, 2022
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