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

RFC: Should docs about clones be part of the scope? #480

Open
avivace opened this issue May 13, 2023 · 11 comments
Open

RFC: Should docs about clones be part of the scope? #480

avivace opened this issue May 13, 2023 · 11 comments
Labels

Comments

@avivace
Copy link
Member

avivace commented May 13, 2023

E.g. Mega Duck, should we start merging/including technical documentation about it in Pan Docs?

@bbbbbr started consolidating the current knowledge in https://github.com/bbbbbr/megaduck-info

What about the Analogue Pocket?

@bbbbbr
Copy link
Contributor

bbbbbr commented May 13, 2023

Thanks for opening the ticket.

I haven't yet come across a more formal place where the Mega Duck info is collected online right now. There appears to be some amount of duplicated searching and asking around people do when looking for the info. Same for the Analogue Pocket ".pocket" format.

I had started dumping some of this stuff in the GBDK-2020 docs (since they're supported consoles by it), but that's not really an ideal place for it. So I moved it to a separate repo for now.

In the GBDK-2020 docs I generally try to defer to and link the Pan Docs for technical info when appropriate, which made me wonder whether any of this Game Boy "adjacent" clone info would be suitable for the Pan Docs. (understanding that some of it, such as tools, homebrew list, etc, would not be even if register/etc info was)

As an overview:

  • CPU/Registers/etc: In a general sense CPU instructions, register addresses and values seem accurate and reliable in my anecdotal testing (compiling games and running them compared with a GB). Have not yet tested Serial link registers (coming.. eventually when time permits).

  • Hardware Info: Still a work in progress (if even appropriate for Pan Docs). There are some people who have mapped the LCD pinout, at this point probably a couple people who have done the cart pinout. etc.

@nitro2k01
Copy link
Member

Absolutely, considering there's maybe a 99% overlap in hardware specifications. I would suggest a separate headline with explains the difference for three hardware categories: functionally equivalent clones (those that nominally have identical hardware apart from the boot ROM), Mega Duck, and Analogue Pocket.

@avivace
Copy link
Member Author

avivace commented May 14, 2023

How about a section at the bottom (just before References) like this:

  • Similar Devices
    • Mega Duck
    • Analogue Pocket
    • (?) Clones

About clones, do we have some, and what should mention about them?

@pinobatch
Copy link
Member

Something about "GB Boy Colour" and "MiSTer"?

@avivace
Copy link
Member Author

avivace commented May 16, 2023

Something about "GB Boy Colour" and "MiSTer"?

Those should be in clones, right?

@bbbbbr
Copy link
Contributor

bbbbbr commented May 16, 2023

Something about "GB Boy Colour" and "MiSTer"?

One way to keep the scope more constrained (to avoid navigating the line between clones and handheld emulators) could be: only cover devices which area capable of executing a program from a physical cart. (so, also excluding copy and then run devices).

I would suggest a separate headline with explains the difference for three hardware categories: functionally equivalent clones (those that nominally have identical hardware apart from the boot ROM), Mega Duck, and Analogue Pocket.
+

  • Similar Devices
    • Mega Duck
    • Analogue Pocket
    • (?) Clones

Sounds reasonable to me.

Seems the main differentiator is derivative devices intended to be compatible (clones) and those intended to be incompatible yet similar to develop for (MD, AP).

About clones, do we have some, and what should mention about them?

Along the lines of what Nitro was saying- maybe what's relevant about clones to the Pan Docs could be:

  • How variations in the boot ROM (or absence of one) effect the startup environment for a program. (different state of vram in some cases, some variation in cpu state).
  • Significant variations in clock speed

A few clones might be mentioned by name as demonstrations of the above.

@aaaaaa123456789
Copy link
Member

aaaaaa123456789 commented May 16, 2023

Adding this information to the main document (as in, callouts wherever there are differences) is very much unwanted noise. I think we're all in agreement in that regard.

As for a separate section, I'm not sure. At what point does this become an advertisement? (Particularly for devices that are still being manufactured.) How similar does a device need to be to be worth documenting here?

@bbbbbr
Copy link
Contributor

bbbbbr commented May 19, 2023

Would you be interested in explaining your concerns about advertising more specifically?

As for device scope - it could boil down to devices where the Pandocs generally apply to them aside from some limited exceptions. Beyond the functionally compatible clones and the intentionally incompatible clones mentioned above, I'm not aware (others might be, ofc) of other non-Nintendo devices which share the Game Boy CPU instruction set and peripherals.

@aaaaaa123456789
Copy link
Member

Would you be interested in explaining your concerns about advertising more specifically?

If we start documenting the differences that currently-under-sale devices have, which may very well be additional features, aren't we advertising them?

@pinobatch
Copy link
Member

For comparison, on a website about homebrew for Nintendo Switch, would it be "advertising" to document the differences among early Switch consoles vulnerable to the paperclip trick, later Switch consoles, Switch Lite, and Switch OLED? And if so, on what grounds might this "advertising" be improper?

@aaaaaa123456789
Copy link
Member

I'd say a fairer comparison would be documenting the differences between the Nintendo Switch and the (non-existent, made up for this comment) FantasySwitch, with 99.99% compatibility with a Nintendo Switch (so long as you flip bit 3 at offset 0xbeef in the header) and full homebrew compatibility.

@avivace avivace added the meta label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants