pokegold VS sm64

If you still want the DVs, they should be 15, 13, 13, 14 for Attack, Defense, Speed, and Special Attack/Defense, respectively, which means the HP DV should be 14. You can find them here (Gold/Silver) and here (Crystal), though the only difference is that Crystal contains an additional entry for Eusine.

One other option is to actually look through the decompiled silver/gold roms, and find the code that actually generates the bytes - then you can copy this functionality on your Arduino.

The most common version of the myth is that in Gen 2, to save on space, each Pokémon was assigned a shiny palette based on its own colors. You can see the notes from a project to decompile Gold's code here: https://github.com/pret/pokegold/blob/1521f52e37741a9220a1362443df6d0462e582d3/data/pokemon/palettes.asm

~330k lines of assembly for gold/silver

Also again, you can compile Pokemon games without a ROM right now from GitHub. Here's Gold for instance: https://github.com/pret/pokegold

Follow the installation instructions

As for your wondering if you could change your name by loading the name entry screen, it might be possible but I don't know if anyone's looked into it (I personally found directly editing my name via boxcode to be easier and more predictable), or if there'd be some unintended consequences from calling that specific routine when you normally aren't supposed to. You'd have to look into how the name entry works (you can find a disassembly for Gold here which has the relevant functions in human-readable assembly), ensure it'll write your name to the correct memory addresses, find the routine's exact ROM address then write a boxcode to call that routine and then safely return to your game.

The SM64 is still going strong https://github.com/n64decomp/sm64

Nintendo won't allow any binaries floating around though.

Romhacks are typically modifying the compiled binary ROM image. Kaze' work is based on the painstakingly disassembled code from the n64decomp project[1]. He's working in C, modifying the game and compiling it again for the original hardware. Not sure I'd call that a "romhack".

Great videos though!

[1] https://github.com/n64decomp/sm64

A team or something reverse engineered super mario. I think that's the repo and it's mostly in C

From course_table.h and course_defines.h we can find that: COURSE_MIN == 0 and COURSE_MAX == 25 - so it looks like every secret stage is a full-fledged "course" for the purposes of counting stars, bringing us to 25 courses + castle stars (COURSE_NONE). So, the maximum possible value for starCount should be 7 * 26 = 182.

Multi-year decompilation project: https://github.com/n64decomp/sm64

The port source code of the decompilation is still up on github and Nintendo hasn't taken it down in years, cause they can't since everything has been done with legal methods

This is false, the source code never leaked; it was meticulously and painstakingly decompiled by hand.

It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL.

I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!