pandocs VS libdragon

Use https://gbdev.io/pandocs/ , https://gbdev.io/gb-opcodes/optables/ and https://github.com/gbdev/awesome-gbdev to get started.

Probably the most important one (the one I've used the most for reference) was the Game Boy Pandocs.

Based on my reading of https://gbdev.io/pandocs/

The pandocs are probably the most up to date documentation about the GameBoy in existence. It's a console which is still under active research - these days it's very focused on the extremely low level hardware behaviour.

The Pandocs are easy to read and contain pretty much everything you need to know to get a basic GB emulator up-and-running. The section on the Power-Up Sequence would answer this question for you and then some. You would've gotten the answer to your question yesterday if you looked at the Memory Map section, which tells you where ROM is mapped, and then some.

Does anyone know of good documentation beyond: - Pan Docs - The Cycle-Accurate Game Boy Docs - Complete Technical Reference - Nitty Gritty Gameboy Cycle Timing

For actual documentation, you probably know the pandocs, but there are a lot of more specific information in the docs linked in their references, especially the cycle-accurate GB docs, the GB complete technical reference by Gekkio. You can also check the source code of the relevant test roms, like the Blargg’s test roms for more general behaviour and the MooneyeGB test suite for more specific things.

For the Game Boy, being a closed system, there's fewer resources. Nintendo made a programming manual, but it's not very good. Pandocs is a good supplement: https://gbdev.io/pandocs/

Very cool article!

If you want to know more about the hardware side of the Game Boy (Color), have a look at the Pan Docs: https://gbdev.io/pandocs/

It's been revamped in the recent years, in terms of presentation. I do kind of miss the old version which had a refreshing "old-school" UI like the RFCs of the IETF, but the newest version is IMHO much more usable when developing an emulator.

Per the Portal 64 creator, the library in question was libultra,[1] which is owned and was distributed exclusively by Nintendo but has been extensively pirated.

There are open source alternatives, including libdragon[2] and libn64[3]. Not sure how feasible replacing libultra with either of those would be considering the scale of the project.

1: https://n64brew.dev/wiki/Libultra

2: https://libdragon.dev/, https://github.com/DragonMinded/libdragon

3: https://github.com/mikeryan/n64dev/

To do 2D on N64, I suggest you to use the libdragon unstable branch https://github.com/DragonMinded/libdragon/wiki/Unstable-branch

I was thinking of doing this for Wii (via GRRLIB), or potentially N64 (via libdragon), but Godot would probably be too resource heavy for the N64, so I'm leaning more towards the Wii.

And an open source sdk at https://github.com/DragonMinded/libdragon libdragon is well on its way to surpassing Nintendo's libultra, but the discord has people knowledgeable about both.

It is pretty much understood in most aspects that pertain regular software development, though there are still corners that are investigated.

The most accurate and fast emulator right now is Ares (https://ares-emu.net), which bundles the Vulkan-accelerated RDP emulation with a recompiler for both CPU and RSP. It is extremely accurate in many regards and in general much closer to the real hardware than any other emulators (with cen64 being a close second). Other emulators manage to run most of the game library but using several hacks, while Ares keeps a zero-hack approach, so not everything works, but it is for instance far more compatible with advanced home-brew stuff which use the hardware in ways that the Nintendo SDK did not.

The most advanced open source library for N64 development is libdragon (https://github.com/DragonMinded/libdragon) which is currently growing very advanced RSP ucodes that do things that are not possible with Nintendo SDK. For instance, it was recently merged a command list support to send commands from CPU to RSP without any lock in the happy path, and fully concurrent access from both the processors. Another example would be its DMA support for fetching data from ROM that exploits undocumented partially-broken features of the RCP that were previously unknown to allow for misaligned memory transfers.

The most accurate source of hardware documentation is the n64brew wiki, which is slowly gathering accurate, hardware-tested information on how the whole console works. https://n64brew.dev/wiki/Main_Page. Unfortunately, it's still lacking in many areas (eg: RSP). It's a painstaking long work because there are many many documents floating around with partial or completely wrong information.

Well...it would be the engine that you write for it, likely using libdragon or something similar as the SDK.

libdragon is what you are looking for: https://github.com/DragonMinded/libdragon