Open avivace opened 3 years ago
I agree with what's been said before on points 1-3.
tl;dr I agree with everything said above.
My personal thoughts and hopes:
I think there are 3 main goals to strive for:
Both! I assume this point is roughly about being a technical reference versus being a programming guide. Ideally we would structure these such that they supplement one another. People should be able to go from one to another without hitting a wall because information is contradicting or oversimplified/overcomplicated.
We don't really have many options other than test/demo ROMs, I think. I assume that information gathered through reverse engineering / leaks will be a no-go if there is no other way to verify things.
Things like CowBite and GBATEK (if given permission) would be good starting points, however we should avoid copy-paste jobs. Even if information is already totally correct, rephrasing and better formatting cannot hurt. Copies of official documentation (like ARM manuals) would be good too. Maybe we can even ask Nintendo to open source the GBA SDK? :stuck_out_tongue_closed_eyes:
What's the objective of the project? Which parts of the GBA hw/sw should be covered in a first minimal subset of essential topics?
I think we should aim to document the GBA hardware with more clarity, depth and accuracy than existing docs like GBATEK or CowBite Spec in an easily accessible and editable format. To properly document the hardware, we should attempt to document the exact what and why of some behavior and not just the commonly observed behavior (see Reading from Unused Memory as a bad example).
For a first version I would suggest leaving the CPU out (link to the official data sheets instead) and focusing on memory layout, IRQ management, DMA, timers, PPU and APU. We should probably leave out any edge cases or special behavior for now and focus on a functional overview first. Details can be added later.
What is the target? Emulator developers or Homebrew developers?
Both. Maybe we can mark information in the document that is mostly relevant to emulator devs and generate a cutdown version for homebrew devs out of this?
How are we gonna prove the stated facts?
I think it's very important to prove what is being stated, but it will be virtually impossible to prove everything. I would therefore suggest that we provide test ROMs for non-trivial information only (example: alignment of timer ticks to the system clock, DMA latching / open bus behavior etc).
Should we use another document as baseline? (E.g. ask nocash to release GBATEK under a permissive license)
We can't really avoid referencing GBATEK I think, but to make sure the document is clean and up to our standards we will need to rephrase and filter the info nonetheless. So I'm not sure if using GBATEK as a direct base will benefit us a lot, but of course clearing out any licensing issues upfront is a good idea anyways.
In the first version it's fine to say "also these are edge cases here if you do it differently, but if you stick to this prescribed way of doing it like this then it works fine."
Follow-up on 4, Tom Happ, creator of CowBite + CowBite spec has given us his permission to "do whatever we want" with CowBite spec.
Is this RFC gonna stay open more long term since it's a very broad topic? Should we update the initial comment to list the remaining open questions?
we should update the first post with conclusions on what we can and move to follow-up issues for the parts we can't conclude on, which helps keep discussion focused.
This RFC marks the start of a community initiated effort in researching and documenting the GBA architecture. Our goal is to produce something similar to Game Boy's Pan Docs.
Some basic points to decide on: